SMGJohn

That is something that would be very simple to remove compared to what I just explained. A secondary task though, first we get to the good bits, and everything else is second. The way the srp even loads in is something that isnt well documented, let alone on a camera.

The issue of nx1 at iso 3200 in video is, imo, nr. The raw pictures at iso 3200 are totally usable, especially when downscaled to 16mp or below. Hence at 8mp they should shine! Instead, video at 3200 is very poor. Hence, there is something 'wrong' going on in the process.

Good news, bad news.

Good news is that I have learned a lot about the srp( samsung reconfigureable processor) architecture. Bad news. It is very very very very complicated. Machine compiled c into binary. Unknown yet when it is loaded into the firmware and if the .cpp files that are listed are infact that, or just other hard ware controls

So the srp is like an fpga in the way you can change what it does on the fly. It differs in the way that it uses VLIW instead of bits to do its magic.
Reverse engineering the binary into something workable.. is possible, but time will tell if and how much can be changed. The plus side of a simple isp changing values in softwear can do something like what the gh2 hack did. The downside being you are stuck with the hardware.
The plus side of the srp implementation.. Building a custom algorithm to..exchange the hevc codec with something else.. Could be possible. Unknown yet if the nr is a part of this or just a software implementation.

Also if the rumors were true about the ml guys approaching samsung, this would be why it didnt happen. They dont release the srp compiler. One instance of them giving access to it at the SAIT school in Korea is all I could find. very very proprietary.

But the dream for me of having a cheap 14bit 6.5k red competitor is what keeps me going. The confirmation of the UHS-II bus sweetens the deal. Going to investigate the possibility of a SD-SATA converter.. I wouldnt mind having a 1tb ssd attached to the back of the camera.


TL:DR This camera is complex and things are not getting easier but still progression is being made.

Sony a6300 is newer and uses s-LOG2, its not a fair comparison. 
Also its obvious HEVC + NR doing something stupid, we all know video mode have NR by now. However if you take a picture at 3200ISO, there is no blue streak ISO artefacts like in video. So its clear that its the NR and in-camera processing causing these artefacts.
You might argue 28 megapixels versus line skipping, but even at the highest ISO I cannot see these streaks, something is going on with the in-camera processing of the video. And we need to shut it off because the 3200 ISO looks usable if the stupid NR just "#&&%¤ off.

Sony a6300 is newer and uses s-LOG2, its not a fair comparison. 
Also its obvious HEVC + NR doing something stupid, we all know video mode have NR by now. However if you take a picture at 3200ISO, there is no blue streak ISO artefacts like in video. So its clear that its the NR and in-camera processing causing these artefacts.
You might argue 28 megapixels versus line skipping, but even at the highest ISO I cannot see these streaks, something is going on with the in-camera processing of the video. And we need to shut it off because the 3200 ISO looks usable if the stupid NR just "#&&%¤ off.

Thanks to some ideas I had regarding hardware and if the nx1 was a true uhs2 camera or just backwards compatibility with uhs2 and thus only being a uhs1 camera I have found proof.

page 3 main pcb shows the full sd slot.
https://fccid.io/pdf.php?id=2394050

The sd slot http://www.alps.com/prod/info/E/HTML/Connector/SDMemoryCard/SCDA/SCDACA0200.html
 Made for uhs2. So the reality of the full speed uhs2 sd bus is possible.

are we talking about hevc support or gpu decoding? they're not the same

Ok, few short notes. 
First of all, there are two operating systems running, tizen and t-kernel based real time OS. What we see and can access is just a nice front end that issues messages to RTOS that actually does all the hard work. If some function is not implemented in it it's unfeasible for us. 
Regarding GUI - I'm working on it now and it's the most hostile toolkit I have ever worked with - EFL. Android is walk in the park compared to this hell.
As you can explicitly set readout to 120fps it either works slower (why?) or faster (240fps declared in the same NX1 launch event that also declared CGRA). 
Cpu cores are most likely based on 1600MHz A9. 

Agree, but please avoid Magic Lantern as menu inspiration as well. IMO the Samsung menus are pretty nice. But Blackmagic really have the menu thing down. Easy and intuitive.

According to this Anandtech article Samsung uses something they call the SRP (Samsung Re-configurable Processor) in the DRIMe-5 SoC. They call it a CGRA (Coarse-Grained Re-configurable Architecture), which probably means it is less flexible than a FPGA but more flexible than traditional IP blocks. I have no idea what their source is, but Anandtech is known for being very reliable. Details about the SRP online are very sparse, but there are a few research papers about it being used as an experimental GPU. Apparently it is used in the last generation of Exynos SoCs as an audio processor (not for their latest chips, though).
The SRP is definitely not being used as the GPU in the DRIMe-5, since the kernel source shows it uses a conventional GPU just like in the Exynos SoC it is based on. It also isn't being used for HEVC encoding, since Samsung has special-purpose hardware blocks to do that. As to what they are using it for, I have no idea at this point.

It was in a cpu config file. But in early firmware, I am plotting the changes and original values to see what sort of leverage can happen with them.
 
This is something that I have also been looking into. With luck it is just the change of an output flag and see if things can be pushed to a higher limit. HEVC and other compression systems are less intensive with less compression, so in theory it should be able to bump up to the bus limit and have less compressed files. In the later firmware the change from 15fps to 25fps for the raw output sort of shows the ceiling of bandwidth the processor can handle. Give or take 30MB raw file x 25fps data stream is 750MBs/6000Mbs
My goal is to see how close to the spec of a red weapon the nx1 can be. HEVC is sort of a pain but the way it works is more like the wavelet based .r3d files when HEVC is at lower compression rates. But the more I find the more interesting things get. And the things they did for this camera make it vastly unique compared to a canon or a sony.
 
The complexity of the nx1 makes that quite hard, if I am correct and there is an fpga/cpld core on board it gets more tricky. I have seen some signs though. No confirmation yet. More work will be done tonight on the dive though. I have compiled a large data sheet already on the things I have found in the first firmware update. But going though the code takes time.
 
And if people are having issues with HEVC I highly recommend getting a GTX960 so far the only gpu with fully enabled on board HEVC encode/decode and boy does it work well. And they are not very expensive. If you go by how HEVC does compression, when you transcode it would be in the Gbs if the data rate is doubled on camera

Which ISO? I used a mangify glass I also turned off OLED colours.
I put it on 3200ISO in darkness also grey background and nothing, if I go to 4000ISO I see RGB ISO noise. I honestly cannot see these blue line streaks you are speaking off in the live view but I can see them in the HEVC files out of the camera. 
I checked both in photo mode and video mode, I will take a picture with my Canon 400D using a macro lens, if you could do the same even with a cellphone if you got any. It would be interesting to see. Perhaps you have a faulty camera or it could also be the OLED colours for all I know.

Just be aware of the risk, we have no clues how to reset the camera if you brick the software and I am sure Samsung Support is not going to be very helpful resetting it for you, who knows but there is a risk

I guess the ideal thing would be to write a virtual machine for running experimental NX1 fw into it. It won't guarantee that no risk is taken once ported onto the real thing, but it would actually lower the risk by a large margin. I don't know if this is easily feasible, though.
 
Another great (but difficult thing) thing would be a "fw pushing" service from a PC, so that you can push a new fw onto NX1 no matter it's state.
Another ideal thing would be a recovery, to be invoked by some keypress.

Of course someone is working on this, if you actually bothered to read it would be pretty clear. His name is Chant and some other people are fiddling around in the system files and looking through the firmwares. 

If you want to troll, go somewhere else.

If you want to troll, go somewhere else.

If i see it right (in the Chart) then the maximum Bitrate for the H.265 HEVC is at Level 5.1 (found this Level in the File-Infos of my NX1-Videos) 160.000 kbit/s, approximately 156 Mbit/s.
And interessting too, the maximum Frame rates:
c4k @ 60p
UHD @ 64p
an FHD @ 256p

I  know by experience that the NX1 is not very sensitive to heat.
I had placed in a vacation my camera at the pool - right in the sun (it was 30 degrees Celsius in the shade!).
After about 25 minutes UHD / 30p recording was still running - despite that one could hardly touch the housing.
Heat test passed! I would say.

The list of additions are interesting, I have to admit the focus will be on video and all other aspects will be secondary.
Found a few things. DRIMe-V clock rate seems to be 200mhz. And that seems.. low. Im expecting an NX1 in the next few weeks, so that is one thing I will test. May have to do some heat dissipation help, but from other things I have found in the fw that should be able to be pushed. If things are on the level of the sony a7(s) line up with their over heating issues I think a tad below that will suffice. The upper limit should be 700mhz+ But erring on the safe side will always be more logical.

**Edit** In additon to that finding, I will have to track the changes to see if they upped the clock rate in the later fw. I am working in the first revision as that has the largest file size, so I assumed it would have the most debug changes from the 1.0 layout, with the other firmwares focusing more on updates and camera usability changes.**
I wasnt intending to work on this tonight as I have some graphic design work I need to do, but the more I look, the juicer things get!

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.
 

Hey, I am currently on a shoot for a music video for 3 - 4 days but I have checked my mail, if nothing I will personally contact Samsung regarding the SDK for the NX1 in the weekend.
My guess is its sensitive SDK with very deep hardware binding codes because no one has leaked it anywhere, which means Samsung is having you write a deal with them to keep it to yourself. I literally spent days searching for it without a single trace of it. 
I personally have no clue what this SDK is, what it looks like and what it does exactly, all I know is what I have read and heard there is no images of it either, Samsung is really keeping it close to the chest and I only read about some people having it, I tried contacting them but no answers. I highly recommend people go around try contact these people whom possess the SDK for the NX1.
I will take a wild guess and assume it looks something similar to the Tizen SDK but with more hardware control, I will just post the image of the Tizen SDK here, however realistically it probably wont be as amazing as we think but it might be a good start to construct our own set of developer tools.

When you produce results do not be shy to ask for donations, I think a lot of people are willing to support you financial including myself. 

When it comes to that point things can be figured out. As I stated, I started this project for my own ideal goals for this camera, I guess its just a plus that more people are interested in expanding what the nx1 can do. The next few weeks will dictate what is possible back end wise. What otto k has also done would be useful. As building a front end like ml would be more user friendly compared to what was built for the gh2 and ptool, and that sort of firmware update system. 
If we could get a list going of what people would like to see it could help focus the work better. Unlike other cameras the firmware is complicated but not near as obfuscated and vastly lacking encryption as other systems. Open source really makes it easy even if the sdk isnt public.

Depending on what I find there could be an option for a 1:1.29 lossless or a higher compression visually lossless hevc. Creating a custom lut for a more red like log seems possible also.
 The firmware seems more of a proof of concept that they left it open to change so many things. And more so to show they can go head to head with the established makers and make something better. Since this thread has garnered more interest I have shifted to put more hours into this dive I am doing.