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.

2 hours ago, DPStewart said:

Turning "off" the Noise Reduction can only be done if somewhere in the lines of code there is a "on" or "off" data entry point. Or if there is something like a line that says "NR level = x".

If nothing like that turns up, then the noise reduction is built into the Codec and won't be removable.

Hopefully the reality is Option #1!

 

 

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.

Just now, Pavel Mašek said:

So it seems that limit is camera's computing power and not card speed. Will try it.

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.

2 hours ago, Tommix said:

Hrr imposisble to use thsi forum, it barely works....cant even write text, some quotes inserted automatically even if i never quote.. Anyways Tugela - dont you ever heard thing such as MARKETING?

How stupid company have to be to say - our 2-3 times cheaper camera is the same as NX1. All companies lie, all companies disables features on cheaper models. The same here with samsung. yes there maybe be different processor but maybe the only diferences is that NX1 proc can handle mic input, can output audio - have more interfaces, this doesnt mean nx500 cpu is less capable in terms of video, photo and it's because both camera using the same sensor. SO would make sense to get most of it, and not create diferent cpu who intentionally reads less data and have worser IQ.

 

PS> but in this monetary world-everything could happen, companies dont care their products, dont care anything but money..so..i guess it may be everything :D

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.

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.

41 minutes ago, Pavel Mašek said:

MB (megabytes) and not same as Mb (megabits = usual unit for bitrate). 170MB/s (megabytes per second) are 1360Mb/s (megabits per second)... so it is completely different level of bitrate.

Vasile hack provides +100Mb/s ( I do not want to brake his request about "not mention" bitrate :-)) so it is higher than default bitrate but still much lower than 170 MBps/1360 Mbps.

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.

3 hours ago, Andrew Reid said:

Things are moving fast guys.

I've created a sub-forum for any subjects which might require a separate thread.

Regarding compression on uploads or attachments, let me know if this is a problem and I will look into it.

http://www.eoshd.com/comments/forum/25-samsung-nx1-hack/

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

2 hours ago, EOS_Lurker said:

Oh my god, the news on this thread is so exciting - I can't express it in ASCII/UNICODE.  How awesome, you guys made my week!  'm a lurker who finally signed up here, just to post a reply:

.."

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

Just now, pressland said:

I don't understand why Samsung didn't implement these changes to start with. I can understand why Sony and Panasonic hobble their consumer models as to not compete with their PRO camera lines, but Samsung had nothing to lose. They could have made the NX1 into an absolute monster, and even charged another $1000.

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

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. 

5 minutes ago, SMGJohn said:

Jesus Christ I had a look at that file and the noise grain is way better looking than my NX1, and I went to see why.

And turns out its got almost 75% more bits per pixel now I know its got half the resolution of the NX1 video, but the more bits per pixel is generally a good thing because the pixel has more information, and the more information the better for everything specially for this kind of resolution, not bad at all.

It will be interesting to see what the higher bitrate will do to the NX1 video and hopefully it might solve the terrible noise streak on ISO 3200 and above.

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.

12 minutes ago, SMGJohn said:

Okay that might be the reason, I tried disable power save in dev mode and it still did it and this time with the 64GB card.

It hits exactly 78 minutes each time, I sat there watching carefully and the file size hits 43GB again. Camera is not even very hot just slightly, the GH4 got hotter after same amount of record time.

I might test this solution of yours later to see if it helps.

There was some mighty fine grains in that H265, what ISO did you shoot at?

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. 

11 minutes ago, Geoff CB said:

http://***URL removed***/forums/thread/3980221#forum-post-57456639

"Duration: 00:00:35.96, start: 0.000000, bitrate: 75059 kb/s
Stream #0:0(eng): Video: hevc (Main) (hvc1 / 0x31637668), yuvj420p(pc, bt709), 2560x1440, 74864 kb/s, 25 fps, 25 tbr, 120k tbn, 120k tbc (default)"

 

 

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. 

42 minutes ago, vasile said:

http://***URL removed***/forums/post/57456860

:-)

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!

2 hours ago, MountneerMan said:

I have not tried any of the hack yet but I agree that I would prefer to not touch the original firmware and not need to flash anything to the cameras internal memory.

IMO the idea hack (if possible) would be somewhere in between what both of you are doing with the ability to reboot into a separate OS from the SD card.

Chant, from what you have seen do you think it would be possible to do this or do you think you would need to flash something new to the camera?

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.

 

30 minutes ago, vasile said:

http://***URL removed***/forums/thread/3980221#forum-post-57456639

:-)

With luck  that will be possible! The di-camera-app is interesting. I found the package info for it last night as well. 

 

15 minutes ago, jagnje said:

If he can get the flat profile of the nx1 on there as well I'm buying it asap.

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.

14 minutes ago, Otto K said:

HEVC seems to be in a separate block as PMU can shut off the power to HEVC block. It's most likely that days from sensor is handled by SRP that does demosaicing, curves, noise and similar and it's then fed to the HEVC block. 

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.

17 minutes ago, MountneerMan said:

OttoK has a really good githud that he is updating regularly. Perhaps you could start a githud page for what you are working on (back end NX1 stuff). Even if its more of just sort of "blogish" updates at this point. I believe github is free but I honestly don't know. 

I am extremely excited reading the progress both of you have been making :). Keep up the good work, both of you.

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.