Hanriverprod

the nx1 will be a solid camera forever. especially if you adapt manual glass, if this is totally dead in 10 years, it'll still be awesome and likely an incredible bargain. I'm sure new cameras will be fine too though, I just can't see the image ever sucking in comparison. we already have raw 6k, and the nx1 looks great. Didn't digital bolex start their company saying they're only doing the one camera? they've updated firmware, but you'll never need to "upgrade", obviously, what's more to want? - maybe I'm mistaken about that though... not a ridiculous concept. your camera being discontinued now is better than upgrading every time sony tells you to

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.
 
 

http://***URL removed***/forums/thread/3988168

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.

My review, mainly sample footage:
 
 

I'm on a film festival committee.  Trust me when I say almost all indy movies look really good these days.  IQ looks on par with just about anything.  Even work that has limited dynamic range still looks pretty impressive.
As for all the other stuff that's actually more important in making a narrative film... well, not so much.
So, if you think what camera you're shooting with is what's holding you back.  IMHO, you're wrong.  So, you pick up and use what you're going to pick up and use.  That's it.  Stop thinking about the limitations of it.  You made the choice, move on.  Now, make smart lighting decisions.  Get a good audio guy (for god's sake please do this), concentrate on telling a good story, and find some actors that can actually do so.
Trust me, no one's going to give two shit(es) if you're dynamic range in 10 stops or 13.  Your skin tone looks a little goofy?  Oh well, I forgive you if you're showing me some interesting characters on screen.

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.

I kind of hope you're trolling, but I feel compelled to respond anyway.
tl;dr: Nobody has been making any implied promises, and your suggestion had already been tried and failed before you posted it.
First of all, nobody is claiming to be working on super-duper secret projects. Everyone has been very clear that they are doing this for fun in their spare time. From what I have read, nobody is releasing much since there isn't much interesting to release. For what it's worth, there have already been results, in particular from Otto and Vasile. Both of them made no promises yet delivered exactly what they said they expected to do. Vasile claimed to have found how to increase the bitrate, and provided a video as proof. Yea he could theoretically have faked it, but I see know reason to think that at this point. Otto stated his intentions very clearly and his results have already proven useful to people who want to take videos of events longer than 30 minutes (as well as anyone who wants to investigate their camera further).
You got radio silence on your suggestions because people were already working on that and ran into problems that you did not address at all. In case it's too much trouble for you to actually read what people have already written, the issue was that if the camera app is killed it freezes the camera. It's hard to replace an app if you cannot even remove it. If you think you know how to prevent that, I would love to hear it. If you want "traction" in this discussion, try actually being helpful.
Regarding the DRIMeV SoC itself, I mostly agree with your educated guess. It is almost certainly the same die, and the ARM cores are 100% identical. Unfortunately that's not saying much at all since most modern ARMv7 cores are identical as far as the software is concerned. It's the details of other blocks that would determine whether or not the important components of the camera application run or not. I can't tell just from skimming the kernel source code.
It takes under 5 minutes to find and download the firmware update from Samsung's site. If you really don't have 5 free minutes in your life, I don't understand why you are wasting time criticizing people who have actually accomplished things and posted them here. If you are 1/2 as smart as you make yourself sound, it should take you less than an hour to unpack all the components of the firmware. I had never unpacked a firmware before, but it only took me two evenings to get all the major pieces out. The offsets, sizes, compression, and filesystems are almost all documented right here in this forum, so there is no excuse not to take a look if you really want to test an idea.
I totally agree that the ratio of people waiting with high expectations to the people working on it is rather high. The Magic Lantern forums are just like that on a larger scale, but that doesn't change what they have or have not done. You need to keep in mind that this forum is a community of filmmakers, not hackers (or even "photographers"). The point of this thread in the first place was to show interest in modifying a camera, at which I'd say it has admirably succeeded!
Finally, nobody cares that you're a busy person. So you like your HoloLens and want to play with it. Cool story. We're all busy people too, so suck it up and either contribute or go back to lurking. Sorry for the tone, but that's because I can never stand people who drop into discussions and claim that they could do it all better if they didn't have so many more important things to do, yet don't contribute anything useful.
/rant

I think he means it happens with LED string lights... Christmas lights. 

I do not think this is an issue with the NX1. This is more of an issue with having too short of a shutter speed. this is almost inevitable with 120p and even 60p if you are following the 180deg rule.

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.

It's a combination of things -
1. Sony cameras don't handle difficult white balance situations with any grace
2. Sony offer a huge degree of options that control the sensor
3. Sony give you profiles that require grading - and I mean, proper, years of experience as a colourist grading, not just drop on a lut or tweak sat and curves
Combine this with low prices and any tom, dick or harry can grab one, stick it in pp9, wave it around a baby with leds, sunlight and an incandescent bulb and wonder what happened to the skin
They aren't cameras for everyone, thats for sure, you can mitigate many of the issues, but they are cameras that demand, in certain modes, a very high degree of cameramanship and skill.
1. Desaturating the higher luminence can work wonders to help take the green and yellow gills away.
2. Stick to pp0, and your fave creative style, if that's too limiting, stick to cine 4, s.gamut.cine. If that's ever too limiting, then you are going to have to start reading technical documentation to understand what the options do and how they do it.
3. Just look at the size of s.gamut 3, and think what is going to happen when you cram all of that into the comparitively tiny space of 709 and understand why colourists can charge what they do. Then never, ever use it.
Or just grab a camera you can get decent results with because clever engineers did all that for you and plenty more besides

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!

Someone wanted to see what JPEG 15 fps image burst was compared to the HEVC, and to say the least the difference is massive not just in the dynamic range but the pure colour information presence in the images, now I have chosen to use 1080p to show the difference as much as possible because its not as noticeable in 2160p, the only difference at such high resolution is the dynamic range, now its clear that JPEG will always be superior to HEVC in 1080p mode and perhaps even in high resolution as well simply because they contain more information per frame. The JPEG have superior resolution as well compared to HEVC even in 1080p, both JPEG and HEVC have the same settings applied to them including sharpness.
Both HEVC and JPEG where colour graded in After Effects using the GammaDR2LOG -> VisionLog - LOG Generic_FujiColor 200_CIN -> Cineon to Film Contrast 01 -> Lumetri Adjustments
In camera settings used for both HEVC and JPEGs are: 1/100 - F/4 - ISO100
JPEG are super fine and resolution: 2048x1152 (Downsampled to 1080p in After Effects)
HEVC are Pro quality and resolution: 1920x1080
 
GammaDR settings:
Red X1.00 - Green X0.95 - Blue X1.00
Sharpness -10
Contrast -10
Luminance 16-235
Master Pedestal not touched
Picture Style Normal settings:
Red X1.00 - Green X0.95 - Blue X1.00
Sharpness -7
Contrast -10
 
HEVC LEFT - JPEG RIGHT
GRADED TOP - UNGRADED BOTTOM

 
I uploaded these files for everyone to try them out if they want to:
103_0326 - 100ISO - https://mega.nz/#!DctRFaIY!eMeqsd-3incYu2IqBZQGW7zINRtwwF8aKO8AFd1gixQ
2592p15 - 3200ISO - https://mega.nz/#!PN0zQIIQ!7tcNWhfTOKDsUYvqZNocFb9bpnMyChdTamdawx5gbzI
3648p15 - 4000ISO - https://mega.nz/#!WdFHkAgZ!8MoMydWK55KXkOnDLR5AlwFslkC4PjZ2YDr2LKSN8KY
 
 

The differences between UHS-2 and UHS-1 are vast. In looking into what card slot the nx1 contained there was quite a lot of info on how they run. The UHS-2 has 8 or so extra pads to do the data rate it is designed for. There could be numerous reasons for the failure. But the max datarate of UHS-1 is 104MB/s So UHS-2 is a must for any of the firmware mods I am going after. More testing is needed though for sure. See how close we can get to the max of UHS-2 write.

The camera is limited by the bus speed of UHS-2 which is 312MB/s 2496Mb/s Fastest card is currently the sandisk extreme pro at 250MB/s 2000Mb/s So there is much more to go until we reach that. Should be enough for what I am looking into. And remember, higher bit rate, lower compression, less math the processor needs to do, so less work and less heat. Theoretically the limit is high, and if you look at the dp review of the canon 80d and the nx1 their new low noise tech is still miles away.

The NX1 is far better with vintage glass than a Canon. More options to choose from as well.

25fps in jpeg, 4608x2592, aspect ratio 16:9, picture quality "super fine", has a bit rate of about 100MB/s.
25fps in jpeg, 6480x3640, aspect ratio 16:9, picture quality "super fine", has a bit rate of about 170MB/s.
The Vasile hack has demonstrated that the Samsung nx1 is able to shoot video over 150MB / s so we are not very far from a new Magic Lantern for Samsung Nx1.

I have found a massive issue regarding record limit on the HEVC, it appears to be more the fault of HEVC screwing around with us rather than the camera or file structure issues.
I tested the MJPEG codec this time around with a 64GB card and the camera plugged into the wall with no battery power to do a record session. Lets just say, just not did it pass the 75 - 78 minute limit the HEVC exhibits.
It clocked around ~620 minutes before running out of space on the 64GB card and froze, I am pretty sure it would last even longer if I had used the 128GB one.

 
 
 
 
 
 
 
 
 
 
 
Now again this is a low bitrate, low resolution video mode that works the sensor less, so I did the test again but this time with 480p HEVC at 25fps, and once more it crashes at 75 - 78 minute mark, its hard to tell the exact mark because its random most of the time. 
I tried both HQ and Normal bitrate but it still crashes above 75~min. files for HQ are no more than over 2GB and the Normal one is half that. Its strange and mystifies me, which concludes that it could be a codec limitation, if the MJPEG can do it, why can the HEVC not do it? Sounds really strange, I am testing the 720p mode as we speak, if it wields the same results I wont bother posting about it, someone else tested 1080p mode which seemed to suffer from the same issues. MJPEG is the only one that not just broke the 78 minute mark but it completely blew me away how long it recorded, it was still going until next morning until it ran out of space and froze the camera.
I will also do a third record session with the MJPEG with the 128GB card to see how long he can sustain record time, I am going to assume its going to be over 1200 minutes which will be quite long time indeed. I decided to share this details simply because it struck me as weird, why would the MJPEG reach 58GB while the same resolution HEVC did not even reach 3GB before stopping, its just puzzling.

I see the NX1 and NX500 have an MJPEG codec, but it's only used for the 640x480 recording mode.
But the codec is there, right? Maybe we could persuade it to record at a higher resolution and bitrate in 4:2:2 like the Canon 1D C. (Ok, wild leap there, but any improvement would be an interesting discovery).
Also the silent shutter, in this mode it does raw from a rolling shutter scan of the sensor, just like a video mode... the raw data must be lurking in the buffer somewhere whilst it runs in video mode... now what we need is a genius to dive in a grab it

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

That is strange, I had macroblockin with the Atomos when I used it could be older firmware or something, whatever it was its just not worth to pay 1500 - 2000 dollars for an external recorder when there is already someone who managed to hack higher bitrate on the NX1, all the benefits you get with the Atomos will surely soon be available inside the camera, the HEVC in the camera if its following the standard set for HEVC, it should come with 10bit, 12bit and 422 + 444. There is also a MJPEG codec in the camera, my prayer to the heaven is someone manages to replace it with the MJPEG2000 codec and enables RGBA4444

I have used the Shogun myself with the NX1 once on a short film, I did not notice much differences or gains so I just shot without it on difficult shots.
I think the NX1 only spits out the same bitrate its set in the menu out on HDMI, I might be terribly wrong but its what I think based on personal experience with the shogun and the NX1