Pavel Mašek

40 minutes ago, Marco Tecno said:

If the macroblocking is still somewhat present at 160mb/sec, could it be the case where it's not due to compressed bitrate but rather to the way h.265 works?

Well, maybe it is more sensitive to macroblocking on plain areas but on other side it renders details so good without any evidence of compression (I am talking now more about 160Mbits). I think the H265 mainly focus on rendering of very fine details (maybe more than H624) and then it has save more of bitrate in plain areas like sky which lead to macroblocks.

These examples above are extreme - ultra wide angle lens with high aperture when complete everything is in focus. I did similar test with 80Mbit some time ago and sky looked like Tetris - so higher bitrate is definitely big improvement. I do not care that is not perfect (I guess 250Mbits would solve it all)  - it is now good enough for most situations. Just check second image - completely no issues even there are plain areas and LOT of details. Maybe disabling in-camera NR would helped too.

26 minutes ago, Andrew Reid said:

Is the top one 80Mbit and second one 160?

In the top one the sky is still macro blocking quite a lot.

Both are 160Mbit. Yes, there is still some macroblocking but:

1. I think it is not so bad and not so visible in video as it was done in quite fast movement and it is very codec stressful scene. Second image was from more still so it is completely fine.

2. I will use 180Mbit (no issues with Lexar 2000x) so it could be slightly better.

It would be interesting to see how would handle same scene eg. 100Mbit H264 Sony A6300.

Another comparsion: 1. 80Mbps, 2. 160Mbps. Less macroblocking, more details, better gradient (open full size image)

While it is just one frame and quite big crop - difference is even more visible in video.

On 7. 4. 2016 at 1:01 AM, Otto K said:

Cross post from dpreview:

As promised I was working on alternative way to run scripts off the SD card without entering the factory mode (as it limits several functions important to me).

Full text here

https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Running_scripts_without_factory_mode.md

What it does: it modifies your root filesystem in camera so it starts a shell script from SD card (if present) every time you start WiFi.

Yes, it's rough. This is a first release just to enable everybody else to test and play around.

Touchscreen works.

Bluetooth works.

Camera works faster than in factory mode.

This might help with increased bitrate as well (don't know, can't test).

Have fun

Otto, sorry again for dumb question - do you think there will be any different method (safest, without using telnet, even for IT dumbs like me) how to do that? I really like this approach but not 100% sure if should I try it or rather wait a few weeks for something easier and "safer"... Thank you!

2 hours ago, Geoff CB said:

Quick test, does not show off fine detail at all, but I do think motion is improved. Forgive my look, I've been very very sick the last couple of days. 

I think it is just not visible in shallow DOF scenes but definitely in complex scenes where everything is sharp, with some movement and also dark areas (all together). Vimeo clip above proves that even it is just static scene.

Below are frames from my 160Mbps video test. Sky would "fall apart" in macroblocking with 80Mbps but it is almost perfect now with incredible details in the branches.

Both are shot with some movement (more in ungraded image) - I just walked around the tree with Sigma 8-16mm...

I would really like to contribute to NX1... but I think I will have chance for it in future :-). Thank you Vasile...

18 minutes ago, Otto K said:

I think this will work fine in future update when tied to bluetooth (as it can be set to be automatically started) plus it would give us an easy "Hack ON/OFF" switch.

That would be so great!

18 minutes ago, Otto K said:

this "hack" is not meant for general end users just yet

OK, I will rather wait - I was able to connect camera via telnet but my knowledge ends there and I am not so brave to change filesystem by myself.

BTW I am curious if bitrate hack will be started outside of factory mode if it helps to increase bitrate even more (for 6,5K video :-D) or had real 120fps (not 106fps etc.). Maybe processor is slower in factory mode and that is why we cannot go beyond 200Mbps or have stable 120fps.

8 hours ago, Otto K said:

Cross post from dpreview:

As promised I was working on alternative way to run scripts off the SD card without entering the factory mode (as it limits several functions important to me).

Full text here

https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Running_scripts_without_factory_mode.md

What it does: it modifies your root filesystem in camera so it starts a shell script from SD card (if present) every time you start WiFi.

Yes, it's rough. This is a first release just to enable everybody else to test and play around.

Touchscreen works.

Bluetooth works.

Camera works faster than in factory mode.

This might help with increased bitrate as well (don't know, can't test).

Have fun

Sorry for dumb question - so if I have Vasile's bitrate hack on SD card and then follow procedure from github it will mean that bitrate hack will be activeted just only in case I will start wi-fi?

15 minutes ago, Antonis said:

You got my attention now!! :D
Could you (or anyone) upload a short example of this onto vimeo/youtube?

On Dpreview user called Mangokid uploaded this video where was used "only" 140mbits. I also done few codec stressful tests but nothing I would like to upload. All I know is that macroblocking is almost gone in 4K30p 160Mbits in most stressful scenes and panning is smoother than before.

2 hours ago, derderimmermuedeist said:

I mean that the panning shot is now also much smoother (with the 160 Mb/s).

Yes, I have noticed that too (especially in 4k), but I thought it is just my opinion. Anyone complained "motion cadence problem" in NX1? I think it is gone now!

12 minutes ago, SMGJohn said:

Oh yeah I completely forgot about the 1080p 24, 25 and 30 being 60mbps and not 80. 

 

Amazing, notice how the moire issue on the roof on those houses to the right completely disappeared with higher bitrate.

Well, it is still there quite a lot - I think just compression is better.

5 minutes ago, Marco Tecno said:

What happens with the frame rate? Why 109?

It seems camera is not able to deliver 120 fps together with high bitrate ... it is my conclusion, I really do not know...

3 minutes ago, caseywilsondp said:

I'm having no such issue... camera boots up at the same speed as before, and no menu/touch screen issues. Maybe I'm doing something different, but when checking the footage it does indeed have the increased bit rate.

Just tested 1080/120 at 180mbps and like mentioned it came out at 109fps and the bitrate was only 160mbps (still a huge increase). However the footage appears to be no different. That was at iso 640, which isn't ideal for this camera at 120, but honestly the 120 is fine at 100-200iso anyways so I was hoping that this would improve that.

Again, just a quick and dirty test, but the footage while having a higher bitrate, is virtually identical in quality.

Maybe it is just because higher ISO which is something that 120fps modes does not like (they are no details so no macroblocking issues).

I am curious what I am doing wrong... will test it more (but I like to hear that camera behaves normaly). 

7 minutes ago, caseywilsondp said:

Seems like the biggest benefactor of this hack is 1080p, which is great because 120 quality was not awesome before.

Yes, but if you consider that it is not exactly 120 fps then it is not so good. If you shoot 25fps then 100 fps could work fine.

I also had problem with macroblocking in 4K30fps but now it seems to be perfect.

Another drawback is (at least for now) slow start of camera, touch display does not work and bluetooth too.

But it is still great if you have 2 fast cards with hacked and non-hacked version...

29 minutes ago, sandro said:

Well 120p is where we should see the best improvements since the bitrate really suffers there. It's not the NR.

Here is comparison of hacked and non hacked 120 fps (200% zoom). There is quite big difference in terms of compression and details.

Problem is that hacked is just 106 fps according Premiere...

First is hacked and second normal:

I still see some macroblocking in shadows in 120fps but I think it renders details better. Buf for now I will stick to 60 fps when using hack.

I think best benefit is in prevention of macroblocking - image is stable and I think also gradient is better. But I did not make any comparsion.

Below is screenshot from graded (and one ungraded) 160Mbits, 4k30fps, Standard, 0-255 videoclip

5 minutes ago, hirsti said:

yes for 1080 @ 120fps but no for 1080 @ 30fps @ 0.25x (or any other speed modified)

I can not agree - I use 160Mbits hack, it has 160mbit in 120fps mode and 40Mbits in 120fps @0.25x. So bitrate is doubled in both cases.

As it was mentioned here before - there is quite major problem that 120fps mode does not work properly. 120fps is not 120fps but around 109 and it seems to be same in x0.25 mode (it is not 29.97 - just sometimes - but 28,99 fps in average what is reported by Premiere).

60fps1080p works fine without any drop in framerate.

4K30fps - Premiere reports is has 29.97 but according Potplayer it oscilates too. But it seems to be OK during playback.

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)

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.

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

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) 

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.

4 hours ago, Last Leaves said:

For me it hadn't been an issue because I transcode my footage to Prores for editing. I don't normally need to play h.265 files back, and when I have I've used VLC without issues up until now.

Now, sorry for the distractions. Does anyone have any idea how we might go about trying to resolve this problem with the NX500 1080p120 "hack"?

It is big question if NX500 is really capable to shoot real 1080p120 fps...

2 hours ago, Last Leaves said:

I am skeptical that it is an apple issue. I'm pretty sure the file produced by the NX500 with the 1080p120 setting is messed up. I have never had any issue decoding any other NX500 clip (even on my brand-new-top-of-the-line-piece-of-shit apple machine that I shouldn't have bought because "really - it's a mac").  I know that variable bitrate can be good, but jumping from 2MB/s to 380Mb/s and back when the only thing changing in the shot are a few falling snowflakes does not seem like a good management of bitrate.

Here are two test files straight off of the NX500's card: http://www.filedropper.com/lastleavesnx5001080p120test

I have checked the footage and I do not see any problem you have mentioned (Win10):

- bitrate is variable but just a little - 37Mb/s to 41Mb/s

- I do not see any artifacts

- it has 120fps but it is not real 120fps footage. It is just 5x speeded up normal 24/25/30 footage. Slowmotion of it is then just normal speed.

- playback worked jus fine in Win media player and also in Premiere

On 1. 4. 2016 at 11:04 AM, Ebrahim Saadawi said:

I would hold the camera during the calibration phase and not leave it on a tripod/desktop. It must have a reference/sample shake to compensate and calibrate the OIS to. 

I thought that too but I have received better result by leaving camera on the desk. I really do not know why... (sometimes I have received even worse results than it was before so I had to perform this test this several times mainly with camera on the desk)