saintsimon2016

There's your answer: HEVC is low bitratre, AVC... not so low :-)

Reported.

Dude, Tommix. Could you maybe not?
How about no to you acting like bully to all of us? Just stop. Either start contributing and stop being a dick to us, or just watch what is happening or lets ask Andrew to get you banned? 


PS: This is not an invitation for you to flame spam this topic so be that kind to us, fellow cinematographers, and get better, friendlier.

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

Has anyone tried to plug an external USB drive directly into the camera and mount it using telnet? I cannot find anywhere if the USB 3.0 on the NX1 is an OTG port.
I was planning on going to pick up a micro USB 3.0 to female type A and play around with it but if someone already has the required cables and knows more about Linux than me this would be alot faster. I would just be googling commands from the internet https://www.google.ca/search?q=how+to+mount+a+usb+hard+drive+in+linux&oq=how+to+mount+a+usb+hard+drive+in+linux&aqs=chrome.0.69i59l2.1280j0j7&sourceid=chrome&ie=UTF-8
 
The intended purpose would be for a program that would back-up all the contents of the SD card to an external drive. This would allow us to back-up our videos(a must with only 1 SD slot) without bringing a laptop to every outing.

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
 
 

Some great work here
Thread is now a sticky topic.

Here is a quick video showing the NX1 and NX500 SD Card Hack for Focus Buttons.
This program allows you to record up to 6 focal points, these are stored on the SD card and will work after a camera restart.
This works for photography, especially good for storing infinity focal point to re-use when it is dark for Astro Photography.
Works in video allows you to do focus pulling from one focal point to another.
Thanks again to Otto for all the hard work, All details can be found on https://github.com/ottokiksmaler/nx500
 

Here is a quick video showing the brilliant work Otto has been doing on the NX500 and NX1 using the SD Card hack.
All details can be found on https://github.com/ottokiksmaler/nx500
 

The code excerpts I posted are from the firmware. The statement about the camera being able to do 240fps is something they didnt remove. Also found a bunch of tizen watch stuff. Bad housekeeping is good news.

But I have yet to find a video output path that is concise. Tons of data on the hevc and everything else, but its what pointed me to the srp and needing to do more research. There way a camera would dump data to an onboard hevc is pretty well documented. Follow the mipi csi-2 bridge a few steps to get to the encoder. but the difference is, if it was indeed just a "hard" core hevc in the drime-v it would be more self contained. Taking what I know of chip construction and "hard" core asic  implementation. The more I do the more I find on how it works and what can be done.

The samsung srp research is also to see if thats what they used, but it it was an onboard hevc asic there would be a lot less code for what Im finding if you go by what tends to control hardware. With luck its srp because Ive found examples of it beings used to do a full 8k6p stream with a very small srp block and the drime-v is a very different beast from the exynos.

But ill just leave these excerpts here.
 
"eSensorModeRollingStillModeOff
eSensorModeRollingStillModeOn
eSensorModePanoramaFull"
"30CBayerImageInformationLiveview
34CBayerImageInformationLiveviewWide
36CBayerImageInformationLiveview120fps
36CBayerImageInformationLiveview240fps"

"LVIEW_PP_CORE_UD
LVIEW_PP_CORE_UD_24FPS
LVIEW_PP_CORE_120FPS
LVIEW_PP_CORE_240FPS"

"eFrameRate24fps
eFrameRate25fps
eFrameRate30fps
eFrameRate33_3fps
eFrameRate40fps
eFrameRate50fps
eFrameRate60fps
eFrameRate100fps
eFrameRate120fps
eFrameRate200fps
eFrameRate240fps"
 
"binningoff
HVbinningon
Hbinningon
Vbinningon"

There has been a few stating that they would like to tip/donate, which would of course be muchhelp,, as I seem to be doing this more than my 9-5 haha! But it is not at a quantifiable stage at the moment, What I have found out is pretty much just a key, and if the key can open the lock is not yet determined. Even with the sdk things of this nature are not 100% 
At any step of the way if they did something undocumented it can halt progress to a point the modification cant be done. Ive been lucky so far with things is all!

But if knowing that what Im doing may not bring a firmware mod to light people still wish to donate then I can put something together. But I started this not knowing there was anyone wanting this camera modded, and I would still do this if no one wanted to tip/donate.

That being said the next stages of what I am doing are copious research. There are white paper behind paywalls but my local university seems to have most of the books on file so I will be acquiring those to get a better idea of the way samsung chose to code.

Personally I am also interested in the lens mount for a working adapter to other lens systems. So the control files are something I am also looking into. As well as if hevc is the best choice for encoding or if something like the redcoderaw would be more suitable which is just their modded version of mjpeg2000. dct vs wavelet is something interesting to read about. 

I believe I have found the sdk for the srp. And quite a few examples of the c scripting style used before it is parsed into the machine state and binary. Working backwards it should be possible to figure out how it is compiled and explore what lies inside the system. It seems similar to an fpga so it shouldnt be very hard to dissect. Things that can be added over just changing the config files. Will update as I go. Keeping these updates short as I have a lot to do with making sure I fully understand the inner workings of this system.

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 Lexar sd card Professional 2000x UHS-II U3, can write 265mbs!

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.

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.
 

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.

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.

Higher bit rate recording for 4K and 1080p (160 Mbps+) Higher frame rates (4K/60 fps, 1080p/240 fps) 2K recording mode and/or 4K crop mode similar to NX500 Ability to turn off noise reduction completely

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

New to the forum, but I have been working on the opening of the firmware for quite a few months. The second I heard about this camera coming from a modded gh2 I knew things were going to be fun.

I had plans to release what I found after having a stable custom build.

Good news after reading this thread as I seem to have quite a bit more discovered than most.

-bootloader
-3d lut info
-rgb888 info
And quite a few more things that make this an ideal camera to mod.

In the interview they basically implied they either had asics or fpgas built along side the arm cores.

"DE: When we were talking previously, you said that the architecture of DRIMe V is very different than DRIMe IV. What sorts of changes are made between them?
JK: The biggest change is the structure of the Image Signal Processor. The DRIMe V ISP is very different. Most ISPs have key parts of the processing hardwired to get the needed speed. What's really new with the DRIMe V is that the "hardwiring" can be reconfigured.
DE: That sounds very significant, although I have to admit I don't know how common it is that ISPs are actually hardwired.
JK: There's not much variability in them. Sometimes you'll get thresholding changes and small numeric variables, but the image path is usually very locked down...
DE: It's pretty much, a fixed pipeline.
JK: With a few tuning pieces, yeah.
DE: Whereas this is more configurable.
JK: Yes.
DE: And it's configurable not at the level of changing a firmware program, but you're actually changing the hardwiring. There are switches you can use to change the configuration of the functional units?
JK: Yeah, basically. And Samsung's software people are all over it; they're pretty sharp and I believe that we're really going to be able to tap fully into the DRIMe V's capabilities for the NX1.
DE: So even though it's hardwired, some of the connectivity is programmable through the firmware, so we can actually look for continued "firmware" development that would continue to improve performance, including the parts that are implemented in hardware.
JK: Yes.
DE: So there may be significant improvements in the near future. That's pretty interesting, because it sounds like it's already starting out pretty capable.
JK: And not just image quality, there's a lot going on in terms of programmability, like we talked about Samsung Auto-Shot mode before. Here's the UI for it."

TLDR: fpga or cpld or asic that can be reconfigd.

Now a few years ago samsung released info about adding fpgas into asics http://www.eetimes.com/document.asp?doc_id=1200317
 
And have teamed up with Lattice on a few projects http://www.oregonlive.com/silicon-forest/index.ssf/2014/04/which_oregon_company_has_a_chi.html
The back end camera control files seem to be written in .cpp so diving deep into the firmware to do a comparison of hex/string/hash changes and tracking the changes across the updates is what I am doing right now. And seeing which values can be modded. Recompiling is a different story but what it seems to be is that building a smiliar man in the middle to what magic lantern would be possible. Have a gui that would simialr to ptools in camera using the web browser capabilities.

Now this is not my full time work so Ive been progressing slowly as I have many projects on the go.
This is also coming from someone who doesnt yet have an nx1. Doing the proof of concept and running the fw in a vm to emulate the possible bricking before things are bought.
I am also tracking similarities to the nx500 to see what things are possible in that camera. Nice b camera which should be able to compete with a shortening of its life but at the cost 10x performance is worth the lifespan limit imo.
 
 

I posted about the work Im doing on the firmware side of the nx1 a few pages back, but it was/still is hidden for some reason. 
**no longer hidden on page 11 at the bottom. Much more detail about what I have found on the camera.**
To sum it up, I have been working on this the better part of 6 months, didnt know anyone else was interested until I found this thread a bit over a week ago and posted my findings. Im at a point of comparing the changes in the firmware versions to see how the code is written. I have uncovered the bootloader, the file format and language used for their custom control files for tizen, info on lut, rgb 888, sd card bus speed(its quite low should be ush1 u3 but its not set close to the speed stated in the sd association docs) and a few more things. 
My goal is similar to what the guy said on the gh2 hack. I had a hacked 144mbs gh2 I used for 5 years until moisture killed it a few months ago. The tech inside the nx1 should be capeable of pushing the hevc and the sensor to the limit, even if it shortens the life by 4-5 years its still cheaper than a red by a magnitude.

Ideal goals for me are raw/compressed raw output, see if cdng or another compressed raw format would work. As red raw is just their version of jpeg2000 modded for cine work.
There is not a deadline I have set to finish this, as this is just one of many projects I have on the go but comparing it to other cameras its quite promising.