Petition for Samsung NX1 hack

[MountneerMan]

40 minutes ago, vasile said:

http://***URL removed***/forums/thread/3988168

let me be the first to say THANK YOU! The download site does not appear to be working. likely because a bunch of people are trying at the same time lol.

Just out of curiosity what is the original Mbit/sec of the NX1?

[sandro]

1 minute ago, MountneerMan said:

let me be the first to say THANK YOU! The download site does not appear to be working. likely because a bunch of people are trying at the same time lol.

Just out of curiosity what is the original Mbit/sec of the NX1?

Pro is 80Mbit but with that script it seems you can go till 320mbit.

[MountneerMan]

2 hours ago, Calum MacPhail said:

The NX1 mounts itself as mass storage via USB at the moment, I think without some serious reworking of the internal Firmware it wouldnt be able to support a storage drive. It would have to be programmed to mount the drive, recognise it as a storage device and then be given the ability to transfer the footage from the SD to the USB, without any external software or hardware. The NX1 may not have the hardware capabilities to achieve this, even with the software, as a mass storage device, its the computer thats doing all the transferring legwork. Even then, it can charge via the USB port, but I doubt it could power a device from the port.

Extremely good points. Especially regarding the power requirement.

Worth trying? I just went to two stores and neither of them had a cable that would work.

[SMGJohn]

2 hours ago, vasile said:

http://***URL removed***/forums/thread/3988168

Let me just thank you so much Vasile for all your hard work so far, I am grateful.

So when I first saw your bitrate hack the first thing I did was testing it, sadly my SD cards are only capable of 160Mbps on the NX1 despite having average 40MB/s writing speed on my computer which should have allowed me to use the ~300Mbps bitrate according to a couple of calculators I used, I could be wrong again, my terrible maths sometime.

While I tested it I honestly could not notice much difference between the shots at 1600ISO, now this is just a quick test nothing in depth really, hopefully someone will do more scientific tests, I suppose you all should take this test with a pinch of salt because it was done in a hurry, I have not tested whether the banding issue is gone either, and I did extensive tests with JPEG's a few days back and the banding barely occurs at normal JPEG compression and completely gone with super and fine, so clearly the issue lays not with 8bit if its fed enough data. My biggest suspicion here because GH4 does not suffer from banding if you know what you are doing, it could be the noise reduction internally which lets face it, destroys details notoriously even at lower ISO's and higher bitrate does not seem to slow it down in its path of destruction.

As always video mode feature my usual settings GammaDR (R1.00 G0.95 B1.00 | -10 Sharpness | -10 Contrast)

80Mbps (Standard Pro Setting) 2160p UHD [1/50 - F/2.0 - 1600ISO]

160Mbps (Vasile's High Bitrate Hack) 2160p UHD [1/50 - F/2.0 - 1600ISO]

320Mbps (Vasile's High Bitrate Hack) 2160p UHD [1/50 - F/2.0 - 1600ISO]

JPEG NORMAL (-10 Sharpness -10 Contrast) 2048x1152 [1/50 - F/2.0 - 1600ISO]

Left 160Mbps - Right 320Mbps

Again, thank you so much Vasile for all your hard work, I really appreciate it even though my results might not prove much but still the bitrate increase is REALLY there, whether the changes are not there could be more the faults of the God damn atrocious HEVC codec which was the biggest mistake to be put in a camera since H264. 

If I have time I will try to record some blue sky if they appear again this week with the 160Mbps setting to see if the banding issue has been negated a bit.

 

 

[digihand]

Has anyone an idea how to turn this on NX500?

- GammaDR (like NX1)

- High bitrate (100+Mbps)

[pressland]

3 hours ago, SMGJohn said:

atrocious HEVC codec which was the biggest mistake to be put in a camera since H264. 

In the case of this camera, the atrocity is the ugly sharpening and DNR. I think people are making too much of the banding issue. Many encodes that reach consumers whether from Blu-ray or iTunes, have instances of noticeable banding even on big-budget releases. Only video nerds with OCD like us will notice or care. In my opinion, the aforementioned issues are much more egregious and deserve the most attention.

Thanks for the comparison shots!

[Pavel Mašek]

I have tried 320 / 250 /200 Mbits with fastest possible card (Lexar 2000x) and it records just few seconds and then it crash with quick "slow card" message (clip with 200Mbits was longer then with 320 Mbits). So it seems that 160 Mbits is only one stable bitrate for now. I would like to do more tests but do not have time for it. However - still GREAT achievement Vasile, thank you so much.

[vasile]

21 minutes ago, Pavel Mašek said:

I have tried 320 / 250 /200 Mbits with fastest possible card (Lexar 2000x) and it records just few seconds and then it crash with quick "slow card" message (clip with 200Mbits was longer then with 320 Mbits). So it seems that 160 Mbits is only one stable bitrate for now. I would like to do more tests but do not have time for it. However - still GREAT achievement Vasile, thank you so much.

I think someone needs to do some more in-depth tests. I do not know how the codec works but based on previous analyses (seen in this thread) of my fish tank video, the codec uses a variable rate. This is supported by @SMGJohn codec info screenshots.

What this means is that the 160Mbit is not really the true rate, it is merely the target average rate for the codec, and that, based on the complexity of each frame, the codec will use less or more bits to encode it.

It is likely that the codec uses something like this: target rate => [min_rate .. max_rate] where min_rate and max_rate are fixed multiples of target rate.

For example (and this uses numbers coming from my hat): 160Mbit/s rate == in reality [0.5x160 .. 2x160] == [80 .. 320] Mbit/sec.

This could be easily be proved with your Lexar card by recording a static scene vs a dynamic scene - the static scene should allow higher bitrates (presumably because it would hover near the lower limit) before the crash.

[Pavel Mašek]

59 minutes ago, vasile said:

I think someone needs to do some more in-depth tests. I do not know how the codec works but based on previous analyses (seen in this thread) of my fish tank video, the codec uses a variable rate. This is supported by @SMGJohn codec info screenshots.

What this means is that the 160Mbit is not really the true rate, it is merely the target average rate for the codec, and that, based on the complexity of each frame, the codec will use less or more bits to encode it.

It is likely that the codec uses something like this: target rate => [min_rate .. max_rate] where min_rate and max_rate are fixed multiples of target rate.

For example (and this uses numbers coming from my hat): 160Mbit/s rate == in reality [0.5x160 .. 2x160] == [80 .. 320] Mbit/sec.

This could be easily be proved with your Lexar card by recording a static scene vs a dynamic scene - the static scene should allow higher bitrates (presumably because it would hover near the lower limit) before the crash.

Yes, that makes sense, that peak of bitrate can be very high. However after quick check I have not seen so big variation in few seconds of 250Mbits footage (but it is too short for proper analysis). Strange is that write speed of the card is still much higher than can achieve peak of bitrate  - maybe there is not enough RAM in camera (according Tommix) 

[Pavel Mašek]

7 minutes ago, Tommix said:

Im maybe card rasist :D but SanDisk is the only card manufacturer -rest is and will be crap  
 

@Pavel MaÅ¡ek hmm when i said there is not enough ram? :D I don't remember that. Anyways so far bitrate looks like is overrated feature better focus on other things. like BITS. Source code full of 10 - 12bit references. 2.5K with bitrate at least 50Mb/s i think 50 is enough for such resolution and h.265 eficiancy.

Never mind - I thought you have mentioned RAM here http://***URL removed***/forums/thread/3988168#forum-post-57561226 

Regarding the bitrate - I saw really awful macroblocking issues in my NX1.  When everything was in focus and sharp then image started to fall apart especially in 120fps mode. I think it is solved now. So grateful for Vasile's work!

Indeed - more bits would be awesome :-)

[Chant]

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.

[Pavel Mašek]

7 minutes ago, Chant said:

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.

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

[Chant]

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

[tugela]

On ‎4‎/‎3‎/‎2016 at 6:07 PM, Tommix said:

 

Pls point me to ATLEAST 1 source file in Nx500 or NX1 where you can prove that CPU is different. YES maybe firmware send different parameters to enable/disable some functions, but this doesn't mean that cpu differs. You not the only one who looked at sources  So far kernel is exactly the same what relates to DRIMeV

The processors are the same family, so they both run the same OS, but that does NOT mean that they are the same. For example, an Intel base laptop i3 will run Windows in exactly the same way as a K series desktop i7, but there is a huge difference in their relative performance.

IIRC Samsung already said that the NX500 had a lower performance processor than the NX1, and that was the reason for the reduced capabilities. And in any case the respective web pages for the two cameras clearly show them with different names, albeit from the same processor family.

[vasile]

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

[ReinisK]

Did a test with 300mb\s in UHD 25p and FHD 100p. The fasted card I have is a Samsung Pro 16gb, which has 50MB\s write speed.

It always stopped after a few seconds. When I put the files in Premiere Pro, it showed weird frame rates. 25fps was in some files 24,77 or something close and 100p was something around 80fps. When the bitrate wasn't hacked, it always showed exact fps, no matter how short the clip was. Another thing - when I brought up the very deep shadows in Premiere. it could very well be seen, that in the beginning of the clip, those shadows consist of huge macroblocks. But when time goes on, those macroblocks get smaller and smaller, until the video stops. It seems that these hacked bitrates need more time to start, and in the beginning the bitrate is somewhat low.

[Pavel D Prichystal]

1 hour ago, Tommix said:

so your empty words is your proof? WHO cares what samsung or other company says? kids maybe. Im grownup man and i do not listen what companies say  People say god exists too, but well it just their word against mine. This is the same. I say it's identical. yes nx500 uses LESS power to cpu, but only because of form factory so needed to keep temp in range so driver adjusts voltage to cpu to lower values than NX1. So that's why samsung without lies can say-nx500 uses less powerful cpu.  I doubt that samsung would invest millions in creating shittier cpu when they just can make it shittier via software.

Pls dont make me laugh when you say to read official webpages :D Samsung also said their 3d is fullHD, and so many other lies. Samsung is propably the most lieing company in the world. At least most times cough to lie.

Dude, Tommix. Could you maybe not?
How about no to you acting like bully to all of us? Just stop. Either start contributing and stop being a dick to us, or just watch what is happening or lets ask Andrew to get you banned? 


PS: This is not an invitation for you to flame spam this topic so be that kind to us, fellow cinematographers, and get better, friendlier.

[hirsti]

I have 2 SD cards that I have tested on, a Sandisk 280 MB/s and a Lexar 2000x 300 MB/s
On the sandisk it is reliable setting the bitrate @ 160 MB/s, if you step up to 200 it will fail after about 10 seconds.
On the Lexar it is reliable setting the bitrate @ 200 MB/s, if you step above this then it fails.

 

[Pavel Mašek]

3 minutes ago, hirsti said:

I have 2 SD cards that I have tested on, a Sandisk 280 MB/s and a Lexar 2000x 300 MB/s
On the sandisk it is reliable setting the bitrate @ 160 MB/s, if you step up to 200 it will fail after about 10 seconds.
On the Lexar it is reliable setting the bitrate @ 200 MB/s, if you step above this then it fails.

 

Interesting - have you tried it with AF/MF, focus peaking ON/OFF, non/native NX lens? Maybe these settings can affect that. I will check it later today too.. My Lexar UHSII crashes after 4 seconds with 200 Mbits (4k30p, AF ON, Samsung 45mm)

[ReinisK]

Hirsti, you mean 160 and 200 megabits, right, no megabytes?

My Samsung 50MB/s card at 200Mb/s goes on for about 40 seconds to 1 minute. With dis it ended after 5 seconds once, but usually no less than 30sec. UHD 25p that is.