Jump to content

Petition for Samsung NX1 hack


kidzrevil
 Share

Recommended Posts

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)"

 

 

a077451e492d4c258e4d24e9d3f38f07.png

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. 

Link to comment
Share on other sites

EOSHD Pro Color 5 for Sony cameras EOSHD Z LOG for Nikon CamerasEOSHD C-LOG and Film Profiles for All Canon DSLRs
5 minutes ago, Otto K said:

@SMGJohn

di-camera-app is leaking (not freeing after use properly) a small amount of RAM every frame it processes. Normally this is not an issue since it does not exhaust the available RAM in 30 minutes, but with time restriction lifted you hit it at ~75min. There are two options to fix this - find a memory leak and fix it in di-camera-app binary (hard) and this possible quick hack if you (or somebody else) is willing to try - create and enable swap file and use it (leaked memory is no actually used and can be safely moved to swap). For some reason swap file on SD card is not working (swap partition might, but it's too much work for an average person), but there is a writeable partition in camera already with ~2GB free, mounted on /opt/usr, so this might help:

First to see hwo things look before (all commands from telnet session):

[root@drime5 ~]£ free
             total       used       free     shared    buffers     cached
Mem:        511580     499896      11684          0       5260      70556
-/+ buffers/cache:     424080      87500
Swap:            0          0          0
[root@drime5 ~]£ df -h /opt/usr
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk0p14       2.3G  105M  2.1G   5% /opt/usr

OK, so we have no swap and have plenty of free disk space on /opt/usr, let's create some swap:

[root@drime5 ~]£ dd if=/dev/zero of=/opt/usr/swap bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 42.882 s, 12.5 MB/s
[root@drime5 ~]£ mkswap /opt/usr/swap
Setting up swapspace version 1, size = 524284 KiB
no label, UUID=63995c82-cf71-43c6-ae32-34e520e7e280

Ouch, internal storage is not very fast... Let's turn it on:

[root@drime5 ~]£ swapon /opt/usr/swap
[root@drime5 ~]£ free
             total       used       free     shared    buffers     cached
Mem:        511580     506540       5040          0       4404      82108
-/+ buffers/cache:     420028      91552
Swap:       524284          0     524284
[root@drime5 ~]£ df -h /opt/usr
Filesystem            Size  Used Avail Use% Mounted on
/dev/mmcblk0p14       2.3G  617M  1.6G  29% /opt/usr

Yup, it works :)

You have to do everything before swapon only once, after that (and after every reboot) you only have to re-enable the swap with swapon /opt/usr/swap

I hope sombody with enough free time tests this, I have a good feeling.

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.

15 minutes ago, vasile said:

I also uploaded the zond demo screenshot for the file.

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

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

26 minutes ago, vasile said:

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

Please pay attention to the first and last phrases in the post.

Good night.

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.

MediaInfo - 03170012 INFO.jpgMediaInfo - SAM_0003 INFO.jpg

Link to comment
Share on other sites

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.

MediaInfo - 03170012 INFO.jpgMediaInfo - SAM_0003 INFO.jpg

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.

Link to comment
Share on other sites

2 minutes ago, Chant said:

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.

Yes the higher the bitrate of the video the less compression happens. I would be happy to test it in my camera, I already tested the factory reset to see if it works and it sure does. 

It resets everything apparently, I screwed around with the temp limits and it reset that back to standard so I am going to assume it works the same way it does for Android phones. However I only have a UHS-1 card as I never saw the need to go any higher at the time I bought it in 2014.

My 3 x SDXC Lexar Class 10 UHS-1 will only write minimum guaranteed 30MB/s which would be 240Mbps bitrate which is still monstrous increase over the pathetic 80Mbps that already exists in the camera, in fact its 192% increase in video bitrate. If anyone would give me the script I be more than willing to run it and make comparisons with original video files.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

46 minutes ago, Chant said:

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. 

Well yes in terms of compression it is, but in terms of details in the image saved, its quite poor to be honest and quite atrocious at lower bitrates, 80mbps is way too low for HEVC it must be way higher to match lets say the 200mbps H264 out of the GH4, you notice fine details like NOISE grain are completely smashed to pieces and smeared in HEVC in the way it works, 8bit is hilariously better at retaining film grain than 10bit is, people tested this.

http://forum.doom9.org/showthread.php?t=170986

Here you can effectively see what HEVC does to finer details, I also noticed that X265 is far better at retaining details specially in low bitrate and against still images compared to the Adobe HEVC encoder which completely dismantles an image. I done tests on vintage BluRay Ghibli movies that have a lot of fine grains in them from the film transfer and I choose animation because they have a lot of flat surfaces that are prone to banding, I noticed the 8bit retains the grain better but still crushes it. 

The entire point of HEVC is to decrease file sizes but retain image quality however this comes at a cost, with loss of details and finer details and images appearing overly smooth. In my humble opinion Samsung picked HEVC was a good choice if it had been an entry level consumer camera or video camera for home usage. 

But for something like the NX1 its bloody terrible, HEVC destroys details the sensor outputs and I honestly believe the entire issue with ISO performance above 3200 is because of HEVC inability to deal with noise grain details at 80mbps bitrate even though that is quite a lot compared to what HEVC is designed to work with. 

Samsung should have stuck with either H264 or even the MJPEG which retains details far better than HEVC. The MJPEG codec is in fact present inside the NX1 which means it would be a walk in the park to switch that one for 4k rather than injecting an entire new codec to the camera. I think we should try enable the MJPEG for 1080p and 2160p to see the difference, from my experience working with HEVC and other codecs you know its terrible when FZ-1000's H264 retains finer details in the image than the NX1 does.

I actually have a comparison shot of the NX1 vs the FZ-1000 and the 1000 has better shadow details with far finer grain noise.

Link to comment
Share on other sites

17 minutes ago, SMGJohn said:

Yes the higher the bitrate of the video the less compression happens. I would be happy to test it in my camera, I already tested the factory reset to see if it works and it sure does. 

It resets everything apparently, I screwed around with the temp limits and it reset that back to standard so I am going to assume it works the same way it does for Android phones. However I only have a UHS-1 card as I never saw the need to go any higher at the time I bought it in 2014.

My 3 x SDXC Lexar Class 10 UHS-1 will only write minimum guaranteed 30MB/s which would be 240Mbps bitrate which is still monstrous increase over the pathetic 80Mbps that already exists in the camera, in fact its 192% increase in video bitrate. If anyone would give me the script I be more than willing to run it and make comparisons with original video files.

I think 200 would be a good pro option. Even if Class 10 UHS-1 can hit 240 you don't want to ride the edge of your card speed.

Link to comment
Share on other sites

10 hours ago, Chant said:

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. 

Hello and thank you for your hard work. Do you think it would be possible to get a subsampling 4.2.2 in Nx1?

Link to comment
Share on other sites

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

By the way, I'd like to ask you all to NOT name the bitrate and let everyone download the file if they want to know it.

It would be an interesting thing to see how long you can keep it under wraps and only discuss "around it" but without naming it explicitly.

I have no way to enforce this [oops, I just realized I do :-) and you know it too] but I do ask you to play by this rule, at least until I am back.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • EOSHD Pro Color 5 for All Sony cameras
    EOSHD C-LOG and Film Profiles for All Canon DSLRs
    EOSHD Dynamic Range Enhancer for H.264/H.265
×
×
  • Create New...