RieGo

Collection of small utilities for bash scripting added to github repo:
popup_timeout ["text message"] [timeout_in_seconds] - displays a popup message for a given number of seconds
popup_ok [message] [ok label] [cancel label] - displays a OK / Cancel dialog, returns 0 if OK, 255 if Cancel
popup_entry [message] [OK label] [cancel label] [sample entry] - displays an entry box with OK/Cancel buttons and prefilled sample text, returns entered text and 0 code for OK or just 255 for cancel.

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

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

Im not going to continue the conversation stating info on what I find. Kernel is irrelevant in this situation. Look up how tizen loads and how the srp works.
If there are relevant updates I will post, Im not going to comment on things to which people seem to just want to troll. Google is a friend use it.

You do bring up similar points about the nx of which I was thinking. But unless we can get the chips uncapped and analized there is no way to know for sure. The power requirement of the srp may have made samsung switch to a asic block for the nx500, as the drimev-s also shows up in the fcc docs as running the not released nx mini 2. 

Now as I stated before there is not much I can post showing what Ive been doing. Dumping ip code is not something I wish to do as that opens a whole lot of legal grey area. Theres a reason the sources dont include everything. They reuse a lot of their ip, and just update the functions inside, as I said I have seen much reference to the nx300 but when you compare the two files there are changes conducive to the hardware the nx1/nx500 runs.

By all means I did not promise anything, although my goals have been stated. With the warning that it may not work the way I intend and doing the due diligence to document and track changes over versions and to compare the findings to the nx500. As you seem to know your way around coding you understand the complexities of binary blobs and reversing them back into c. 
The script stuff that otto k and vasile are doing show promise, and in the past month things have moved very fast. If you were around when the gh2 was being modded it took quite a while for ptool to happen. Not saying they are the same but having the ability to up bitrate and access other parts of the os is nothing to scoff at. 

I can either keep posting tiny parts of what Im finding and documenting as I go or do what I have been the past two weeks and work and ignore what is going on here until situations like this arise and I feel compelled to reply.

Tommix, no way. That's why I say there is something wrong in the bench. Going from a samsung pro to a lexar 2000x is a huge jump on my camera. You go from about 1fps when buffer full to 5/6fps. And the clearing time is about 3-4x better.

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

I was curious if in-camera playback will work with high bitrate hacked video. Andrew mentioned in old article ( http://www.eoshd.com/2014/04/nikon-d800-hacked-50mbits-high-bitrate-recording-option/ ) that D800 was not able to playback its own hacked videos.
So I have put Vasile's high bitrate hacked clip to SD card and try to play it in my NX1 ............. and it works without any issues!
So now I am curious how high can we go with bitrate to keep playback working :-)
BTW - ISO in his clip jumps from 400 (brightest parts) to 1250.

Minor update, still doing what Im doing, still digging and documenting what changes Im finding in the firmware, have started to explore with telnet and the camera. Its looking good. Have a few ideas on how it utilizes firmware updates but nothing solid yet. But I like how both stages are progressing. Although i wish I had more to show haha but dumping c isnt going to have a point! I should have a major update in a few days though!

I'm using an up-to-date Premiere Pro and nowadays it's no problem at all to work with hevc. the only thing premiere has difficulties with is reading the color range 0-255 from the NX1.
if you got performance problems you probably just need hevc hardware decoding (intel skylake or nvidia 960 or 970 i think)

i'm on windows.
i see your point. new tech definitely needs some time to get widely adopted... let's just hope in a few years it will be as compatible as h264. in the meantime the only option is to convert the files before working with them, or hopefully someone can get some different encoding working on this firmware.
only time will tell

On my past trip to NYC, I edited all of my footage (hevc) natively in After Effects. I had no trouble at all editing and rendering my NX1 footage (finally no more converting!).
https://youtu.be/0zN78OuY5Hs

I'm using an up-to-date Premiere Pro and nowadays it's no problem at all to work with hevc. the only thing premiere has difficulties with is reading the color range 0-255 from the NX1.
if you got performance problems you probably just need hevc hardware decoding (intel skylake or nvidia 960 or 970 i think)

seems like that com.samsung.di-camera-app is something like the complete gui of the camera. at least it contains all icons and images.
so i'm currently taking a really close look at it as well 
too bad it's a compiled binary... 

well, you can use the 2d/3d 45mm nx lens to capture 3d.
so i guess you can watch it at least on your tv afterwards 
it also mentions dropbox and youtube and stuff, that's really weird.

Just testet (with the tool in Dev mode) in Camera:
Transcend SDXC 64GB UHD-I:
Read: 68.571 KB/s
Write: 37.873 KB/s
 
Lexar SDXC 64GB UHD-II:
Read: 88.619 KB/s 
Write: 68.374 KB/s

seems like that com.samsung.di-camera-app is something like the complete gui of the camera. at least it contains all icons and images.
so i'm currently taking a really close look at it as well 
too bad it's a compiled binary... 

Let's tease out and document the full functionality of the prefman tool, what settings it can change and how...
https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Prefman_tool.md

Things are moving fast guys.
I've created a sub-forum for any subjects which might require a separate thread.
Regarding compression on uploads or attachments, let me know if this is a problem and I will look into it.
http://www.eoshd.com/comments/forum/25-samsung-nx1-hack/

Interesting tool in firmware (at least on NX500): https://github.com/ottokiksmaler/nx500_nx1_modding/blob/master/Prefman_tool.md

Time limit hack works for NX30, NX300 and NX1100 for all video recording formats including 60fps 1080p. NX30 and NX300 shows 3579139 for total duration for all videos, if last two digits are decimal points, it will roughly equate to 34.67 GB corruption mark. 34.67 gb converts to 35502.08 and 35791.39 mb converts to 34.95 Gb.
NX1100 had a time duration showing instead of a constant, different times for different formats. NX1100 does not have an AE button, but substituting the Trash button worked to gain access to Dev Menu.

Yesterday filmed in 4K the korfball Play Off - Sports Event + 720p livestream to youtube with the "DEV" hacks to disable 30 mins limit and lens check.
Camera NX1 proofs to be stable, even in stress conditions of the sports event! 
Camera: NX1 Lens: Canon Broadcast J17ex7.7B4 Record: 2160  25p on Komputerbay SD card Video out: 1080P for Youtube livestream Great work and many thanks :-)

please stop thinking i don't think h265 has trouble at higher bitrates compared to h264. this is heavily dependend on the encoder used. and we are talking about hardware encoders, not software encoders that have been optimized for 10 years.
i highly doubt the NX1/NX500 would have better quality with h264 at the same bitrate. and furthermore if there's no h264 encoding chip on the board there's no chance to do it anyways.
at 4k resolution no one should be using h264, IMHO
(this was a post based on personal experience and my own opinion)

please stop thinking i don't think h265 has trouble at higher bitrates compared to h264. this is heavily dependend on the encoder used. and we are talking about hardware encoders, not software encoders that have been optimized for 10 years.
i highly doubt the NX1/NX500 would have better quality with h264 at the same bitrate. and furthermore if there's no h264 encoding chip on the board there's no chance to do it anyways.
at 4k resolution no one should be using h264, IMHO
(this was a post based on personal experience and my own opinion)

@SMGJohn I've seen your video before . I like the look a lot. What's with the blockiness on the shot of the helicopter alone in the sky?
Even back when NoamKroll reviewed the NX1, it was pretty obvious that the camera could have some good information if you protected the highlights and underexposed slightly. That's a camera characteristic that should be independent of the codec. 
While you could raise shadows before and see some detail, you'd see a lot of smearing because of the coding trees. Now that the bitrate is higher, from what I understand, HEVC will dynamically end up making smaller coding trees to produce more data without the smearing. (I hate that it's now inaccurate to say macroblocking!). Thus the information is now less blocky and more deliverable.