Chant

Just caught up with this thread, are most people formatting with the windows/other os format program? Ive been using https://www.sdcard.org/downloads/formatter_4/ For the longest time it has worked way better than anything windows does, as my first test with a sandisk extreme pro 32GBs uhs-1 gave me 200mbs right off the bat. Try this and reformat the cards and see if you gain speed. Might work for the uhs-2 card that seem slower than they should. Still sorting through firmware and dumping data from the camera. My day job has gotten busy so I have not had the time to post here but I have not slowed down my work. But whats happened is amazing, seems like more people are finding these mods, maybe samsung will notice.

Ive seen portions of the fw that point to when its enabled, Bad news is its deep in the fw. Part of what ive been doing is working on how to make things like this be possible. Although the mjpeg is a different story. But I have many nots on that subject. I have priorities with my work though, and much of it is secondary to my focus, but its not an impossibility. I am looking for directions to where it may be able to be disabled or limited and enacted through scripting but as of yet nothing has come to fruition. As Ive stated my updates are less forthcoming as there is so much to do I am still sorting through the fw and tracking how things do what they do. But I keep finding things that are to my expectations and assumptions which is good when building something like this. I have also spotted a few things that may allow the camera to boot from a save state off the sd so somthing like magic lantern could be possible. Yes to confirm. But again things point to it being a possibility

I was more meaning test the line that is the full integration video record test and log what happens. Which modules the pmu activates, the file output etc. So "st app nx record run full" Ill test it when Im done work tonight though. There is a lot of code to go through in the di camera app, and I did maybe 1/4 of it last night Found a few things like that. Mainly looking into the hevc block and that jazz. I do like how quickly the scripting side of things is going though! So much progress so quickly!

Some interesting things in the di-camera file ######## RECORD TEST STARTED(%d) RECORD SINGLE THREAD STARTED RECORD SINGLE THREAD COMPLETED RECORD UNIT THREAD STARTED RECORD UNIT THREAD COMPLETED RECORD commands: Usage: st app nx record [cmd,...] start: do record start stop: stop video record pause: pause current video recording. resume: resume current video recording. resolution [show,name]: set video record resolution run stop stop current running test run count [n] set the max test count as given value (0: infinite) run unit do video record unit test run single do video recording while changing resolution run basic do record test while changing mode and video resolution run full do full integration video record test help pause resume resolution Usage: st app nx record resolution [show,name] Usage: st app nx capture run count [n] Set the max test count as %d unit single basic Usage: st app nx record run [mode] unit do video record unit test single do video recording while changing resolution basic do record test while changing mode and video resolution full do full integration video record test If anyone wants to test. No time for me tonight.

Well for how the dis works it could be using up ram that could be allocated for buffer to write. But more testing is needed for sure

For the NX1 I have done a stablity test going from 320mbs down and the 200mbs worked best on a 3 year old 32gb class 10 Sandisk extreme pro uhs 1 card. If you use constant focus it crashes the card 1/5 times, switching to manual focus and back to constant seems to work. Its a good leap on the scripting side of things! Try running the camera in manual mode and ois/dis off.

Im not going to continue the conversation stating info on what I find. Kernel is irrelevant in this situation. Look up how tizen loads and how the srp works. If there are relevant updates I will post, Im not going to comment on things to which people seem to just want to troll. Google is a friend use it.

You do bring up similar points about the nx of which I was thinking. But unless we can get the chips uncapped and analized there is no way to know for sure. The power requirement of the srp may have made samsung switch to a asic block for the nx500, as the drimev-s also shows up in the fcc docs as running the not released nx mini 2. Now as I stated before there is not much I can post showing what Ive been doing. Dumping ip code is not something I wish to do as that opens a whole lot of legal grey area. Theres a reason the sources dont include everything. They reuse a lot of their ip, and just update the functions inside, as I said I have seen much reference to the nx300 but when you compare the two files there are changes conducive to the hardware the nx1/nx500 runs. By all means I did not promise anything, although my goals have been stated. With the warning that it may not work the way I intend and doing the due diligence to document and track changes over versions and to compare the findings to the nx500. As you seem to know your way around coding you understand the complexities of binary blobs and reversing them back into c. The script stuff that otto k and vasile are doing show promise, and in the past month things have moved very fast. If you were around when the gh2 was being modded it took quite a while for ptool to happen. Not saying they are the same but having the ability to up bitrate and access other parts of the os is nothing to scoff at. I can either keep posting tiny parts of what Im finding and documenting as I go or do what I have been the past two weeks and work and ignore what is going on here until situations like this arise and I feel compelled to reply.

Please reread the whole thread, the nx1 and nx500 cpus are not the same at all. They reuse a lot of code, Parts of the encoding blocks reference nx300 things, it doesnt mean they are the same as the nx300. The architecture may be similar but from what I have seen code wise is quite a lot of difference, yes both are tizen, both have very similar control file structures, but look into them and the function calls change for obvious reasons, now Im not saying you cant use code from either, just that like everything it would have to be adapted. and modified with the proper nx1/nx500 references.

Minor update, still doing what Im doing, still digging and documenting what changes Im finding in the firmware, have started to explore with telnet and the camera. Its looking good. Have a few ideas on how it utilizes firmware updates but nothing solid yet. But I like how both stages are progressing. Although i wish I had more to show haha but dumping c isnt going to have a point! I should have a major update in a few days though!

The differences between UHS-2 and UHS-1 are vast. In looking into what card slot the nx1 contained there was quite a lot of info on how they run. The UHS-2 has 8 or so extra pads to do the data rate it is designed for. There could be numerous reasons for the failure. But the max datarate of UHS-1 is 104MB/s So UHS-2 is a must for any of the firmware mods I am going after. More testing is needed though for sure. See how close we can get to the max of UHS-2 write.

The camera is limited by the bus speed of UHS-2 which is 312MB/s 2496Mb/s Fastest card is currently the sandisk extreme pro at 250MB/s 2000Mb/s So there is much more to go until we reach that. Should be enough for what I am looking into. And remember, higher bit rate, lower compression, less math the processor needs to do, so less work and less heat. Theoretically the limit is high, and if you look at the dp review of the canon 80d and the nx1 their new low noise tech is still miles away.

When Im off work Ill post up what Ive been doing and the things that have happened with the route Im doing. I suggest that otto k and vasile when he is back start a new thread containing the work they have done, as they are pertaining to different things and their updates come more quickly than mine! I will also post up the info in a github of the progress but I think it would help the organize the information better

I removed teh rest due to the size of post. But no you cant just put the nx1 bin into an nx500. Now what Im doing it may be possible to change the type of encoding that will happen. As the current progress is more to do with scripts modding the front end to greatly simplify terms. But the nx500 is after the nx1 firmware mod wise. And we will see whats possible. Pandoras box isnt opened yet, but we found the map if an analogy works

One can just hope they see what the community has done knowing that the nx was at end of life I probley just bought one of the last ones that were at adorama has 1.32 firmware on it. Make them rethink the choice and maybe come back with the rumored lx version. I think it was called. But now that I have one the discovery and research time into firmware is going to go up. And as much as things moved the last week I think things will happen much quicker than with the other cameras that have been modded. Good bye sleep haha

This is more along the lines of what I am working on. The bitrate mod that they did should be good for most. But I am diving deep into the fw, Still a good time away until my end shows any gains. But like I said a few posts ago the more I find the more excited I get. I can look at the mjpeg encoder cpp and see if things can me modded to allow a higher frame size. But again thats just adding to the list of things. But at least things have moved up! Maybe samsung will have an official word the more news of these mods get better known

Well remember HEVC is 2x better on average compared to h264 so at 240mbs it would be a 480 mbs h264 file and something like a 2400 mbs mjpeg file. I think its a 10x better compression to mjpeg that is in the canon cameras. I just did a color correction test to see what can be saved from the shadow detail and there is a ton of data. So at a higher frame rate it should be even better.

With a uhs-2 the upper limit is 2.4 gbs so that is that hard limit, and pushing the encoder should be easy, as the higher the bitrate the less encoding that happens weird as it may be. So that is something to test if someone wants to see what it can do.

He might have had it set to the 25% zoom. It happened to me yesterday, the menu isnt the best on zond but it works. Id like to see how the quantization is though! But still has a 400ms 12 frame gop. So changing that will help a lot.

Can you turn on the quantization and repost and then post the comparison to the oem setting. on the menu under the video frame on the left it is the button with the square and the guy running.

Awesome, do you have a stream parser so you can compare the two bitrates? zond 265 worked for me. They have trials as most are very costly. Do a sample with the before and after frame rate and then see what the analyzer says. This is a step for sure!

That is hard to say, might be able to load something like magic lantern, but the way the camera uses the .cpp files firmware wise make it limiting in what can be done. ML uses a modded firmware with a boot flag to enable what they use. But can be added to the list of things to look into. There will probley be a few variations of firmware, I found a log file of what they did to test and try to break the firmware so imitating it could be helpful. With luck that will be possible! The di-camera-app is interesting. I found the package info for it last night as well. Flat or log or cine gamma. All similar but not if you know what I mean. My want is for something to be similar to red.

It seems that way, or at least going down the bit stream things are implemented. There is so so so so many cpp files as you have probley seen. But thats part of the task haha! The hevc stream is interesting if you feed it into a parser. the compression is very dynamic. But pumping it up to the max of the sd bus speed could garner results. The gop of the file I tested was 15frames(500ms) So there is some possible quality improvements from there.

Some interesting tidbits found tonight. "setpath 0 - 2(0:OTF/1:IPCout/2:RawOut/3:Ldc Out/4:120FPS OTF/5:120FPS IPC out 6:120FPS Raw Out/7:120FPS Ldc Out/8:panorama/9:MFZoom)" "sensorframerate 12,15,20,24,25,30,40,50,60,100,120,240 outputframerate 12,15,20,24,25,30,40,50,60,100,120,240 dataframerate 12,15,20,24,25,30,40,50,60,100,120,240" Still looking for the encoder though. To confirm srp or other hardware. But the closer it gets. And then the real fun happens! I can look into the nx500 firmware deeper after I do the nx1 and see what can be added or changed. I do have a want for a nx500 b cam, especially as a gopro stand in due to them being cheaper! Make everyone want this samsung gear now that they cant get them. Maybe it was samsungs plan all along. Edit "HEVC Encoder %s:%s(%d)> Width(%d) or height(%d) is not multiple of 8 %s:%s(%d)> HEVC[%d] Cfg WH %dx%d %d, BR:%dkbps GOP:%d > size 0x%x > return %d" the full sensor read out should be possible with this also notice gop setting and bit rate. I will have to look at the encoder.cpp file which is where things get more complicated but this is very good news.

I have a few githubs for other projects and its a good idea. it would be more of a blog, the amount of data I have examined would be too much to try to make sense of, as I said, I was working on this for my own personal goals a few months before I even found this thread. Ill see if I can create something tangible in the next few days github wise and Ill post up. Alas text cant convey how excited I am as I go through all this info. I had a want for it to be a good system and it has surpassed my expectations. Great things can be done with it.