saintsimon2016

Yes Marco, it's a speed booster prototype selfmade. It's possible. In the nex time I post my full work on it, and begginning the test on NX1 camera.

First video: "Samsung NX100 + Speed Booster prototype". 
For my test, I use the Samsung NX100 camera with Nikon Nikkor 50mm f1.4.
 
 

I started already (but will be away until Aug)- see here for details.

nx-patch v5.3 is out. One point of interest to videographers: killall switch added which basically returns camera to factory settings (until battery pull) EXCEPT for the already set bitrates. Pull battery to reactivate mod UI.

Shot with vasile's 140 mbps. Still from 4k on 1080 timeline. Andrew's gamma DR settings but no LOG LUT. Just used visioncolor impulz rec.709 tetrachrome FC + Curves, saturation boost and vignette. Used 16-50S lens.

Sick footage everyone! I'm surely having fun with the NX1!!

I am now doing groundwork for mods that will be a lot more advanced. This is why you are likely to not see any visible progress for a while. In essence I am trying to zombify the di-camera-app to enable bi-directional communications between it and my mod infrastructure, and to introduce the possibility to "drive" it from the mod runtime..
If successful this should allow many things, potentially including native UI integration, true BBAF, native integration of focus stack & focus pull, etc. etc. My plan is to make it an extensible and open framework upon which others might build on (e.g. Otto) to deliver things that work in coordinated manner with the native app, and that are aware of what the native app does. This will allow, for example, to have the UI permanently up to date regardless of what the mod does (as opposed to today where mods do not update the UI because they are independent of di-camera-app).
NB. Nothing above is a promise or commitment and you do not see any timeline, do you?
PS. I still covet that lens ;-)

Samsung NX1 16-50S Hack: Vasile 5.01 150mps Normal Gamma, Costum profil, Premiere CC with R709 LUT, Filmconvert Grain 50%

this :-). Have fun.

From @NXKS2

Removing crop-factor and custom resolutions on NX500.
... it appears that we can control the crop factor (remove it) and even have custom resolutions, by controlling the EP_Resize registers. As you can see for NX500 all non-crop simply have the same value for the scanning and output (ex VGA), where the crop modes have one scanning resolution and another for the output (ex DC). For removing the crop, we don't even need to recalculate values, just repeat the input to output value. However setting those is a bit trickier than expected....
4K DC
[20826000] 0140000E 10000000 0438000C 08700000
VGA
[20826000] 05000000 05000000 03C00000 03C00000

Source: https://www.facebook.com/NXKS2/


 

thanks a lot for the detailed explanation. i really enjoyed reading through it!
 
I guess you have to rethink this. the camera doesn't actually encode 120 frames per second. it encodes 30 frames (my tests showed it's probably 25 frames) in one second of realtime. once it finished (or more probably also while) recording it tells the container that this, say 1000 frames, should be played back at 120f/s. which makes it basically really fast -> timelapse. camera didn't have to do any more work than in 30p.
btw take a look at http://***URL removed***/forums/post/57866447 for framerate/resolution/slot tests and sample files

I think its easier if they managed to get 1080p and 2160p MJPEG instead

Ok this is going to be fun.
BTW in case you wonder why I have time and state of mind to write this long post, see here :-(.
So all you have so far is two contradicting claims coming from me and KS, and you cannot be sure which of us is right.
Let us rectify that. I attach the spreadsheet I used to calculate the bitrate values - you will need to keep it open in Excel because otherwise you will not be able to properly follow the rest of my post. NB. you will need Excel 2013 or later because it uses some Excel functions that were unavailable before Excel 2013.
I also attach a print screen for those of you who would rather not download it and instead look at a picture :-), or do not have Excel 2013.
Unfortunately the machine I am writing this from does not have Excel 2013 either so I cannot plug in the 40Mbit value - but you will see that the spreadsheet calculation gives the exact value I used and KS quoted - see cell E48 (If you want, tonight I will post an updated picture).
BTW if you have not heard of hexadecimal (base 16) numbering which is used in computing because it is easier :-) just remember that instead of numbers containing 0-9 you will see in the spreadsheet many numbers using 0-9 and A-F (coz base 16). If you are unfamiliar with this, do not be discouraged - I will not ask you to make any calculations.
So, if you are ready to invest 10 minutes in understanding where do the rates come from, here we go:
When I looked into the newly broken-in NX500 it was obvious that the di-camera-app was the program to look into - the name makes it so. So my initial objective was to see where the bitrates are set - well, to cut a long story short, I identified the place in a certain function call, and I saw that the bitrates were loaded into a CPU register via a couple of ARM instructions (different for each bitrate slot).
These instructions are called mov.w and movt. The end result of running them one after the other is that a 32-bit value is loaded into a target CPU register. For the bitrates, the target register needs to be R3 (except for nx500 pro bitrates which need to be put in R0 - note that KS did not say what is the cause of this exception).
Now we go in really deep.
Basically we need to re-encode these instructions such that instead of loading into R3 whatever bit rates Samsung marketing decided, they should load whatever __I__ wanted.
From now on I will start each paragraph with the cell you need to look at.
Cell D9 - So let us pick the target value - in this case 85Mbps.
Cell D10 - to keep things easy let us convert it in a 32-bit hexadecimal
Cell D11 - let us not forget the target register (for nx500 pro bitrates we would change this to r0)
Cell H5 After thoroughly reading the relevant section of the ARMv7 reference manual, I built the tables H5-AM9 and B13-AM23. Let us discuss then a bit.
The two ARM instructions I am trying to assemble are each 4 bytes = 32 bits. Since this is little-endian ARM, the values are stored in memory as shown in table H5-AM9. that is, a bit scrambled :-). If you read the ARM reference manual, you will see that these two instructions are very similar, the only difference is that one loads a 16-bit value in the lower half of the target register (mow.w) and the other of into the upper half of the target register (movt). They are encoded with some fixed bits (background white in the tables) and some variable bits which contain the 16 bits that make up the value to be uploaded into the register (yellow background).
So now all we have to do is split the 32 bits of the target value into two sets of 16 bits, and spread these 16 bits into the dedicated yellow spaces reserved for them.
Cell B13 Let us start with mov.w  (cell B13). The mov.w neds to contain the lower 16 bits of the target value - see cells E14 and E15. These 16 bits I then manually (ok through formulae) sprinkle into the proper yellow places in the encoded ARM instruction.
I then do the same for the movt instruction. The upper 16 bits from the target bitrate I "sprinkle" into the necessary places within the encoded instruction - see cells B19-AM23.
So now we have the ARM instructions codes, exactly how they look if we dump the memory: see cells AB16 and AB22.
BUT, since I am going to use gdb to patch the memory, they are inconvenient, because gdb would require four set statements if I tried to patch byte by byte the memory. So what I decided was to make out of these 4 bytes an integer (which can be patched with one gdb set statement). How to do it? Well, because ARM is little-endian, I needed to reverse the memory byte order to arrive to an integer that gdb will use for patching. Hence cells AB17 and AB23 - notice that the bytes are in reverse order compared to what you see in the memory. This is because gdb, when putting an integer into memory, will know ARM stores them in reverse order and therefore will do the same. The net result is that we end up with the proper value in the memory.
Finally, again to make my gdb task easier, I decided to concatenate these two ARM instructions together so I do not mismatch them and because they are easily split again in gdb. I did that in cell AD25.
So now all we need is to add the surrounding text to make it simply a copy/paste in the gdb script and thus avoid re-typing errors. This I did in cell Q27.
But this calculates only ONE bitrate value, and I am lazy so how can I force Excel to calculate all of them without me having to replace each value in cell D9? Well, Microsoft was kind enough to provide for array operations (I think they are called so) and I took advantage by telling Excel to basically replace D9, successively, with the values I wanted, and store the result in a table. You will find the table in cells D46 to G82.
From there I simply copied the result into the gdb script I publicly released.
Now if you have gdb, go to the memory addresses that change the bitrates and compare my spreadsheet results with the original SAMSUNG values, you will see that they match perfectly: the instructions generated by my spreadsheet are CORRECT - every instance of original Samsung bitrate set instructions, read from memory, matches the corresponding value calculated by my spreadsheet. This proves that the elaborate construction I put together in this spreadsheet is correct.
Finally, for those who open the file, there's a second section of the worksheet that I did not discuss, and which is basically the development of the algorithm used by my current nx-patch and which calculates on the fly the bitrate allowing you to set it to whatever value you want. This development I integrated ad-literam in my nx-patch - see bitRateOpCodes function in nx-patch.cpp.
NB. This is a very very short explanation of my thought process how I went from zero ARM assembly knowledge to encoding these instructions, by using the ARM reference manual.
I hope this post will clear any lingering doubts about the correctness of my calculations.
 

NX wip v18.xlsx

DR of 180Mbps footage. Great thing is there is no macroblocking in lifted shadows, just litle lack of details... but still very good result I think. 
BTW - First image is unedited 0-255, Standard, MBL +8. Second is converted to 16-235 with some grading (also added saturation becuase there was lack of colours in shadows and just a little bit sharpness to left side of image)
 

 
 
 

@kidzrevil 
You just need to follow instructions on the dpr page, but I can put them here:
How to install:
1) start with a clean memory card (no files)
2) unzip the contents of the zip into the root of the sdcard
3) put card in camera, and restart
x) to uninstall mod - from custom menu> settings> Uninstall Mod
To change bitrate start the camera wait for [loading complete] message push EV button see menu and take "bitrate" option. There you can insert all numbers for each quality option, also you can push "current" and change current bitrate which camera operates right now, e.g. your last settings

I can confirm Outerbeats findings. I was lurking in the shadows until something bigger happens, but my video assignment for today made me to step forward and try to install the hack.
To my findings it was super easy and the hack works perfectly with my budget card Transcend Ultimate 600x 64GB SDXC 90MB/s Class 10 (which offeres best price/performance for the lowest price). The card heats up, but as others said already, until its hot to melting point (which won't happen), no problem at all. With that NX1 can do
- 200mbit for 6 sec
- 195mbit for aprox. 6,5 minut
- 190mbit no stopping after 12 minutes.. 

Not sure what changed, but great job guys, very much so!

could the following be used on the NX1?
 
From here: http://x265.readthedocs.org/en/default/cli.html
 
--nr-intra <integer>, --nr-inter <integer>
Noise reduction - an adaptive deadzone applied after DCT (subtracting from DCT coefficients), before quantization. It does no pixel-level filtering, doesn’t cross DCT block boundaries, has no overlap, The higher the strength value parameter, the more aggressively it will reduce noise.
Enabling noise reduction will make outputs diverge between different numbers of frame threads. Outputs will be deterministic but the outputs of -F2 will no longer match the outputs of -F3, etc.
Values: any value in range of 0 to 2000. Default 0 (disabled).

Congrats for all the effort guys (Chant, Vasile, Otto...).

I'm very excited to see all things you are implementing on this cameras.
Now with the new Blackmagic View Assist 4K i was wondering if (even on our more remote dreams) would be possible to get a RAW image via HDMI.
I have no knowledge in this area and i apologize if it's a stupid question. Take care and keep up the good work!


 

I honestly doubt it. I think even mjpeg 4k would be huge improvement, but Vasile is more oriented towards video hacks, I'm more on basic and low level functionality as well as stills.  

eoshd is the "other" board mentioned here :-)
http://***URL removed***/forums/post/57589144

No idea but I doubt it w/o replacing the codec. Chant might eventually be able to do something about it but don't hold your breath. At the moment I see a slight chance to get:
more resolutions (i.e. 2.5K on NX1) the high rate 2.5K on NX500 (subject to dangerous manipulations on burner cam) maybe higher res and rate MJPEG out of NX1 (although TBH I do not think it would reach the quality of 150-160 Mbps hevc) with a lot of luck disable or reduce video NR (I might take a look at this at some point in the future but this will definitely involve weeks of work so not too keen to start). Basically Chant is looking into adding true new stuff.
I have been looking more on the side of tweaking what's already in there - easier than Chant's ambitions but I already picked the low and medium hanging fruits.

Useful (I hope) for both NX1 and NX500 users: http://***URL removed***/forums/post/57583300

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.

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.
 

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 have mentioned this previously on other forums, the H.265 codec profile used within the NX1 is limited to 160,000 kbps, it's MAIN - Level 5.1, to go higher you need to change the codec profile. To get to 10bit the NX1/NX500 needs the newer version of the codec without which it is impossible.
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding