I don't think I currently have the experience or time to successfully modify the NX1/NX500 firmware. I don't even have one of those cameras. However it would be a shame to let the interest in this die, so I guess I'll post some of my notes/thoughts about the firmware in hopes that it might help keep the ball rolling.
Note: if you aren't into technical minutiae, the only interesting part of this wall of text is the bulleted list at the end detailing what is and is not possible in my opinion.
Here are the files listed in the header of nx1.bin (version 1.4.0):
version.info: offset=0x0 size=0x3F (same as found in /etc/version.info)
linux image: offset=0x0130 size=0x00624748
idk: offset=0x624878 size=0xD8E9
linux image: offset=0x632161 size=0x3192E8
linux image: offset=0x94B449 size=0x638518
idk: offset=0xF83961 size=0x01FF10
idk: offset=0xFA3871 size=0xB35140
rootfs: offset=0x1AD89B1 size=0x117A89FF (lzo compressed ext4 filesystem image)
opt: offset=0x132813B0 size=0x58E91C (lzo compressed ext4 filesystem image)
pcachelist: offset=0x1380FCCC size=0x7000 (PAGECACHELIST, preceded by a header, I think)
idk: offset=0x13816CCC size=0x35BCC44 (lzo compressed. header indicates swap image?)
Anyone with the skills to reverse engineer a camera could figure this out pretty easily, but it was fairly tedious so maybe this will save someone 20 minutes of poking around in a hex editor. If anyone knows what's up with the files I've labeled "idk," I would love to hear about it.
The checksum algorithm is fortunately unchanged from the NX300 as far as I can tell.
As documented at sites.google.com/site/nxcryptophotography/diy-firmware
"width=32 poly=0x04c11db7 init=0xffffffff refin=true refout=true xorout=0x00000000 check=0x340bc6d9 name="JAMCRC""
"jacksum -x -a crc:32,04c11db7,ffffffff,true,true,00000000 [file]"
The main camera app binary is (I'm pretty sure) located at /usr/apps/com.samsung.di-camera-app/bin/di-camera-app in the rootfs. It seems to access the hardware through a relatively high-level API with the /usr/lib/libmm* libraries. libmmf-camcorder.so is particularly interesting. The function I've focused my attention on is mmf_camcorder_set_attributes(), which comes from libffm-camcorder and is used repeatedly in di-camera-app. It conveniently (and strangely IMO) takes strings as identifiers for the attributes that are apparently being set (why not just an enum? I suppose I shouldn't look a gift horse in the mouth...). Some of those attributes include "target-time-limit," "audio-encoder-bitrate," and "video-encoder-bitrate." The guy who successfully removed the recording time limit on the NX300 did it by modifying the instructions that set the variable being passed along with "targe-time-limit." I found the control flow instructions he mentioned in that thread, so it should't be hard to get rid of the time limit on the NX1, provided the camera accepts the modified firmware. The NX500 is probably similar. The "video-encoder-bitrate" attribute also looks promising, though it would take some more advanced reverse engineering to figure out where the values are being set.
So from what I've seen and read, here is what I think is and is not possible to modify on the NX1 and NX500:
Remove time limit: Highly likely. Seems to be the same as the NX300. Pretty easy too, if there aren't any new security measures in place.
Increased bitrate: Possible. Needs some real reverse engineering to find where the rates are set for each resolution and quality.
Noise reduction and sharpening: Possible. Haven't seen anything that looks like it's controlling these, but if setting the bitrate works, this should be possible too. FWIW I think that increasing the bitrate would help with the noise reduction issues. H.265 tends to smooth things out a lot to achieve low bitrates.
Re-enable 2.5k on NX500: Plausible but difficult. It depends on whether they just removed it from di-camera-app, or if they removed it from the underlying libraries as well. Either way it would likely require actually adding control flow to the binary, which opens a whole new can of worms. Beyond my current ability, for sure.
Focus peaking for NX500 4k: Maybe? I have no idea, really. There might be a good reason they didn't include it, there might not.
4k crop on NX1: Plausible but even more difficult. We know the hardware can do it, but it was probably never implemented on the NX1, even in pre-production.
Gamma profile on NX500: Plausible. Similar to porting the NX500's 4k crop to the NX1, I think.
6k 24fps H.265: Highly unlikely. The H.265 encoder would have to support frame sizes larger than DCI 4k and be able to handle twice the pixel rate (clock speed) of 4k. Furthermore it would require implementing a brand-new video mode at a very low level. I can't say for sure it's categorically impossible, but don't get your hopes up.
10bit H.265: Nope. The H.265 standard does indeed allow for 10bit encoding, but I highly doubt Samsung would include the significantly larger (wider busses, more complex encoding) hardware necessary to do it. It would be a miracle if Samsung had really decided to go to all that effort and not use it.
6k or full sensor 4k at more than 30fps or 1080p at (significantly) more than 120fps: Impossible. The image sensor simply isn't fast enough. If you hope for this you will just be disappointed!
RAW Video: Not really. It might be theoretically possible to dump the live-view feed as in Magic Lantern. Who knows how fast the SD card interface is, though. Certainly no more than 1080p. I can imagine tricking the GPU into packing 12bit 4k RAW into 1080p 444 HDMI like Apertus, but consider that a pipe dream. Don't get your hopes up.
Anyway, that was longer than I expected, but I enjoyed poking around in the firmware, so I don't regret it even if it comes to nothing. It's a shame Samsung appears to be dropping the NX line; they are cool little cameras.
p.s. If you know anything I've said is wrong, please correct me; I'm learning this as I go along.
MOV_SIZE on NX1:
dc24p=0
uhd30=1
uhd24=2
uhd23.98=3
fhd120=4
fhd60=5
fhd30=6
fhd24=7
fhd23.98=8
hd60=10
hd30=11
vga60=12
vga=13
mjpeg=14
i think i give 9 a try lol -> seems like 9 sets it to fhd24
btw: someone did the same for NX500 at dpreview: http://***URL removed***/forums/thread/3985980
Absolutely agree with this one,
1. Most important - Higher bit rates is the thing we all need the most. Lets get rid of macroblocking and all sorts of problem.
2. Turn off the NoiseReduction - in my mind, the NR must slow eat a big chunk of processing power. If turned off, this power can be used elswhere.
3. 10 bit or 12RAW - I mean, honestly. You cant argue with this one..
4. Higher frame rates - is what makes the camera more appealing to us, but honestly, not more usable. Just makes it a better deal
5. Trying to disable crop 4K on NX500 and applieing 1 to 4 to NX500. That could make the camera more appealing to everybody. (not sure if we established already this is not possible?)
PS: Chant, as other stated, if you are dedicated to this task.. As other stated, dont be shy to ask for compensation or think of crowdfunding from us, if you plan to break in the camera and make it whole new better piece of tech.
Argh! I typed a silly long post and then hit backspace outside of this box and ... poof ... it's gone
OK, shorter version:
If you start telnet server as described and connect to camera you can do following:
killall dfmsd; sleep 2; dfmsd -p &
This will kill original dfms daemon and start a new instance that we can now use by dfmstool command that sends commands to daemon like this:
dfmstool -s "this is a command"
Be careful, as soon as it encounters an invalid command it stops processing all other commands so we need to do killall... to restart it (it does not affect the camera state).
The command we want is sys_param movie size 2560_1440_30p. Yup, it's still in the firmware, it has no crop and it supports peaking. Why they removed it from the menu I have no idea. It's labelled as MJPEG on screen but it records HEVC as others and is limited to 29:59.
dfmstool -s "sys_param movie size 2560_1440_30p"
Here's what ffmpeg has to say (I have to find a way to set the quality as well):
Stream #0:1(eng): Video: none (hvc1 / 0x31637668), 2560x1440, 11280 kb/s, 29.97 fps, 29.97 tbr, 120k tbn, 120k tbc
Oh, yeah, remember how there is no 1080p at 120fps in NX500? Think again:
dfmstool -s "sys_param movie size 1920_1080_120p"
And output of ffmpeg:
Stream #0:0(eng): Video: none (hvc1 / 0x31637668), 1920x1080, 38589 kb/s, 119.88 fps, 119.88 tbr, 120k tbn, 120k tbc
If you really want to you can put just the command in the nx_cs.adj file and call it a day (dfmsd will parse it and finish) or put a small script in test.sh that will do it for you (there is no touchscreen available while dfmsd is running). You could have SD cards for special video modes to simplify it.
For NX500 full list of modes is
4096_2160_24p
3840_2160_30p
2560_1440_30p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_15p
1280_720_120p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p
For NX1, full list of modes is (yeah fractional ones too, don't know whether they are just for show or are there really differences between 24 and 23.98 when recorded)
4096_2160_24p
3840_2160_30p
3840_2160_24p
3840_2160_23_98p
1920_1080_120p
1920_1080_60p
1920_1080_30p
1920_1080_24p
1920_1080_23_98p
1920_1080_15p
1280_720_60p
1280_720_30p
640_480_60p
640_480_30p
Well, that's it for now, have fun
Tommix, as far as I can tell, the process is all but simple. As pavel wrote, patience is a keyword here. Otto created some nice scripts. Vasile seems to have upped the bitrate. Chant is delving into the main code.
Three must be the conditions joined by a logical AND:
- Interested in nx system
- higly knowledgeable in sw development and Linux system
- have time
just for reference. i logged all values. maybe someone is interested.
prefman values on NX1:
if this is too much text for this thread let me know, i couldn't find any spoiler option
