Petition for Samsung NX1 hack

[sandro]

Well at least we know the cpu can handle saving 60p 4K :D

[lucabutera]

I hope that in the next update samsung update the hvc2 codec.
Hvc1 has too many limitations, many image problems are caused by this.
Hvc2 with Hack and high bit rate would be a big leap.

[sidi]

54 minutes ago, sandro said:

Well at least we know the cpu can handle saving 60p 4K :D

I would much prefer 1080@120p or did I missed it?

[kidzrevil]

4k @ 60p would be incredible on the nx1 ??

[Marco Tecno]

5 hours ago, sidi said:

I would much prefer 1080@120p or did I missed it?

Nx1 can already do that...

[sidi]

1 minute ago, Marco Tecno said:

Nx1 can already do that...

Weird I've edited this post and it didn't stick 

I'm talking about NX500.

[Blasst]

51 minutes ago, kidzrevil said:

4k @ 60p would be incredible on the nx1 ??

Yes it would. I could be very happy with my NX1 for a long time having 4K@60p.

[SMGJohn]

8 hours ago, lucabutera said:

I hope that in the next update samsung update the hvc2 codec.
Hvc1 has too many limitations, many image problems are caused by this.
Hvc2 with Hack and high bit rate would be a big leap.

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

[kinoseed]

On 5/31/2016 at 8:26 PM, Otto K said:

@vasile is correct - if you are not sure what you are doing - don't do it. Added a large warning to github. 

And one should be very careful what values are used if you mod the bitrates.
for example lets take 40mbps, vasile's mode has: set $bitrate_040 = 0x2362F2C02300F645
However this is not the bitrate that should go in the address, but the real one is: 0x4ff4b443c0f26223
(and of course nx500-pro has a spacial case)

so keep that in mind too, if you plan to make changes you better use the real bitrate values

ps. if vasile's "had it" or not is his problem, but so far what I said were only facts

ps2: if you have questions, or look for the latest info/downloads for nx-ks, please use the facebook page, as I don't check the forums often. https://www.facebook.com/NXKS2/

[kinoseed]

btw, if you are wondering how "set $bitrate_040 = 0x2362F2C02300F645" actually "works out" in the end:
- it's written backward in pairs (to get what you set in memory, you get the last pair "45" from the end and make it first, "f6" second, and so on), which was rectified before setting in memory, so you in effect set this:
0x45f6023 c0f26223
which gets you half way to the correct value, which is:
0x4ff4b443 c0f26223

Thankfully the miscalculated first part is of non significance, so you get the bitrate, even though you set garbage in 50% of the memory patch.
again, be very sure what you patch and where

[vasile]

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

[kinoseed]

Before someone again asks for dna-proofs and starts spreading his sheets, and to avoid "measuring of calculations" contests...

here's a short clarification (ex 40mbps):

when you look at vasile's code you will see: 2362F2C0 2300F645
when you use vasile's mods you end up with those values set in memory: (45f6023 c0f26223)
where these values: (4ff4b443 c0f26223) are set by SAMSUNG for the same bitrate, before any mods, and for sake of sanity, let's take them as the "correct" ones.

( you can verify that yourself )

That closes the topic about the bitrate values as far as I am concerned.

[outerbeat]

On 02.06.2016 at 0:13 PM, sandro said:

Well at least we know the cpu can handle saving 60p 4K :D

Well, as I said on dpr, codec can do even 4K @ 120 fps, here it summary of files that I record, camera was able to create a file with this properties:

Width : 3 840 pixels
Height : 2 160 pixels
Frame rate mode : Constant
Frame rate : 119.880 fps

So, UHD @ 120 file is exists and it's smooth. With dublicates though (every 11th = every 10th frame). And it's x4 speed timelapse. But in principle it is possible.

[Marco Tecno]

I'd be already happy to have 4k@60 and fhd@240

[tugela]

3 hours ago, outerbeat said:

Well, as I said on dpr, codec can do even 4K @ 120 fps, here it summary of files that I record, camera was able to create a file with this properties:

Width : 3 840 pixels
Height : 2 160 pixels
Frame rate mode : Constant
Frame rate : 119.880 fps

So, UHD @ 120 file is exists and it's smooth. With dublicates though (every 11th = every 10th frame). And it's x4 speed timelapse. But in principle it is possible.

Not really. Even though your file says "120 fps", it is actually being recorded at 30 fps. It is being shot at a lower bit rate and then conformed to a higher bit rate for playback. You could conform it to whatever playback speed you wanted to in principal, it would just be a matter of setting a flag somewhere. There is nothing to suggest that the camera can handle shooting at the higher frame rate however. The critical limitation is the amount of information the camera can handle RECORDING, not doing playback. I doubt that the processor could handle the amount of raw data coming off the sensor to record 4k at 60 fps.

[RieGo]

7 hours ago, vasile said:

...

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.

thanks a lot for the detailed explanation. i really enjoyed reading through it!

 

3 hours ago, outerbeat said:

Well, as I said on dpr, codec can do even 4K @ 120 fps, here it summary of files that I record, camera was able to create a file with this properties:

Width : 3 840 pixels
Height : 2 160 pixels
Frame rate mode : Constant
Frame rate : 119.880 fps

So, UHD @ 120 file is exists and it's smooth. With dublicates though (every 11th = every 10th frame). And it's x4 speed timelapse. But in principle it is possible.

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

[kidzrevil]

4 hours ago, Marco Tecno said:

I'd be already happy to have 4k@60 and fhd@240

Same ! ??

[bristo]

Some questions before hacking the NX1..

Hi, I read all this thread and I'm about to hack the NX1 with vasile 4.13 release. (did not have time to hack before)

However I am not sure to fully understand the way to do it know with the patch.

I downloaded a file from github : nx-patch.zipv4.13 - OK OK now activates; 30 min limit auto-removed

But on my mac it does not appear as a zip file but as a simple file called: nx-patch containing some some others staff...

In the readme text it says I have to unzip something but do not have anything to unzip?

So in order to hack it I just have to copy the nx-patch file  on my SD card on follow instructions explained in the readme with bluetooth etc...

Am I right?

 

 

 

[bristo]

Ok in fact after going thru github and dpreview forum I am completely lost????

I fell really stupid but I can not understand how to do the hack?

How and where do I found the zip file?

Which hack do I have to install in order to increase the bitrate and have a kind of reliability? is it version 4.13 but I do not understand how to download the file ???

I am really sorry but if someone can take a minute to figure it our I would appreciate...

[Otto K]

Download this file https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/video-bitrate-mods/nx-patch/nx-patch.zip?raw=true

And extract it to SD card root so that the file info.tg is in the root directory of your SD card. I don't have a Mac but I guess this should be trivial from any file manager. 

*absolutely read the Readme file*

Then put SD card in camera, remove battery, reinsert the battery and power the camera on. Follow the instructions.