Pavel Mašek

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.
 

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.
 

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.
 

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
 
 

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

Well well well, do 30-days for a minor felony and I come back to THIS! A bit-rate hack. Outstanding.

Now, I'd like to make very clear that in the case of the GH2 just increasing the bit-rate often caused as many new problems as it fixed. Generating a compressed image involves a whole slew of data factors that affect each other. That's why there was like 200 different hack patches folks made as they tried experimenting with the different data points.
Many of the attempts simply crashed or injected all sorts of other instability. Some made certain artifacts worse. Some fixed one thing but broke another.

The fact that this mod can double the bit-rate is amazingly promising. And remember - you often won't see any "overall" difference. Especially because this camera generates such a great image already. I would advise looking only at the areas that previously had been problems. That's really all we need anyway. Just those few problems fixed. Then this camera is much more of an all-around winner.

SD-Cards: I would not even attempt to record at these new high bit-rates without a card like the Sandisk Extreme PRO or a similar card. You're begging for heartbreak if you do.

We may very well find that there are hidden data matrices that need to work in conjunction with each other to do things like lessen macro blocking, over sharpening, and noise.
That's what there was on the GH2's. It's reasonable to expect some similar complications.

Rock-On everybody!

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:
 

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:
 

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:
 

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:
 

Tried to test that allocation unit size and if it does anything to improve the slow card problem.
Everything was tested at UHD 25p. Adapted lens. Samsung Pro 16gb SD, 50MB\s write speed, 200mbps hack enabled. Exfat.
Tried to set it with 1024 bytes (min value) - couldn't record more than 3 seconds even without DIS.
Tested it with max value (32768 kilobytes) - could record around 10 seconds without DIS.
512 kilobytes, 4096 kilobytes, 32 kilobytes - a bit better, but still with DIS on no more than 10 seconds, without DIS around 1 minute, sometimes more, sometimes less.
So couldn't get 200mbps working. Also the camera was really slow when turning shutter or iso dials.
160mbps seems to work with and without DIS, also the camera is much more responsive, though not in the level as without the hack. Did this with 32kbytes allocation unit size.
So my conclusion is that as long as you don't set this value to extremes, it doesn't have a huge impact.
Iso 6400 at 200mbps doesn't look much different than at 80mbps.

Hi.
If I format the card as ext4 the camera reports it cannot read the card format.
I have formatted back to exFat with an allocation unit size of 4096 which seems to be more stable for 200Mbits/sec, I haven't had any failures for clips less than 1 min but occasionally it will fail over 1 min.

Reported.

Sorry, I mean the options in the nx1-pba.sh file
160Mbits/sec and 200Mbits/sec
I am running with DIS off and a Manual Focus lens.
I have been testing a bit more and noticed that if I run at 200Mbits/sec after a battery removal it will be pretty consistant, however if I have been using the camera for a while then it does crash out after about 6 secs.  I have only recorded clips under 1 minute.
I have reverted both cards back to 160Mbits/sec, I have just recorded a 25 minute PAL 4096x2160@24fps with no issues.
 

1. read this: http://www.magiclantern.fm/forum/index.php?topic=5827.25
2. read this too: http://www.magiclantern.fm/forum/index.php?topic=6278.0
3. format (in your PC) the SD card with larger block sizes
4. test
/done exfat test
5. If you are a Windows [the horror, the horror, I pity you] user, either go here: http://www.ext2fsd.com/ or here: http://www.paragon-drivers.com/extfs-windows/ [if you like proprietary stuff]
6. then format your SD card in ext4, without journal and with a largish block size (8192 or 16384)
7. test again
/done ext4 test
8. report back here
There, I just gave you a replacement for tonight's sleep :-), and therefore a chance to join me in missing sleep :-)
rgds
PS. I have high hopes for ext4 since it is a native Linux format whereas exfat is Microsoft and may well be implemented as a fuse filesystem which performs much much worse.

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.
 

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.

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.

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.

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.
 
 

Some things related to hacking and video modes. Based on examining /sys/devices/platform/drime5-pmu.1/ during operation. This is a power management unit (it shuts down blocks that are not currently used - a very definite source for what's being used when):
During MJPEG block called mp is used (also in video preview)
During HEVC block called hevc is used, but mp as well (also in video preview)
Block called srp is used only during SAS mode, not during video
Block called pp is always used and I have a hunch (just a hunch) that noise removal is included in it (same name in various places during any image processing, memory allocatin, etc, even just for displaying)
This strongly suggests that both hevc and jpeg are done in dedicated hardware, not something that can be easily changed (but migh accept various parameters, etc).

I'm quite certain that it is actually 23.98p not 98p, but it's written as "3840_2160_23_98p". I hope I'm wrong.
 

I think it depends on type of benchmark - even if you test it on PC:
Kingston Mobilelite G4 USB3 UHSII reader
Sandisk 64GB UHS-I Extrem PRO 95M/s
R/W 
USBDeview - 42MBs / 92MBs
SpeedOut v 0.5  - 85MBs / 88MBs
USB Flash Benchmark - max. 91MBs / 92Mbs
BTW - I have received my cheap Lexar 2000x 64GB UHSII ( http://www.ebay.com/itm/181946939074?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT ) . It is little bit suspicious as Lexar brand is taped up by some Chinese holografic signs. But I have test it and seems to be OK.
NX1 - average around 66MBs / 88 MBs
USBDeview - 67MBs / 220MBs
SpeedOut v 0.5  - around 220MBs / around 220MBs (here is limit USB reader)
USB Flash Benchmark (it depends on file size) - max. 220MBs / 220Mbs (here is limit USB reader)
I simply do not trust NX1 benchmark - camera definitely writes faster according what I have already tested with burst shots.
 

OK, but according this logic (at least) all first four cards should achieve same speeds in the dev benchmark - if camera would be the limit factor. Because they are definitely faster than shows this dev test. My Sandisk Extreme Pro 95MB/s can achieve almost 92 MB/s write speed with best card reader.
Going to Lexar 2000x still means benefit of another 15 MB/s (53MBs vs 68MBs in dev test). Why there is difference in speed if cards are much faster than camera can use?

I think it depends on type of benchmark - even if you test it on PC:
Kingston Mobilelite G4 USB3 UHSII reader
Sandisk 64GB UHS-I Extrem PRO 95M/s
R/W 
USBDeview - 42MBs / 92MBs
SpeedOut v 0.5  - 85MBs / 88MBs
USB Flash Benchmark - max. 91MBs / 92Mbs
BTW - I have received my cheap Lexar 2000x 64GB UHSII ( http://www.ebay.com/itm/181946939074?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT ) . It is little bit suspicious as Lexar brand is taped up by some Chinese holografic signs. But I have test it and seems to be OK.
NX1 - average around 66MBs / 88 MBs
USBDeview - 67MBs / 220MBs
SpeedOut v 0.5  - around 220MBs / around 220MBs (here is limit USB reader)
USB Flash Benchmark (it depends on file size) - max. 220MBs / 220Mbs (here is limit USB reader)
I simply do not trust NX1 benchmark - camera definitely writes faster according what I have already tested with burst shots.