Jump to content

vasile

Members
  • Posts

    95
  • Joined

  • Last visited

Posts posted by vasile

  1. 57 minutes ago, Pavel Mašek said:

    Here is comparison of hacked and non hacked 120 fps (200% zoom). There is quite big difference in terms of compression and details.

    Problem is that hacked is just 106 fps according Premiere...

     

    you might want to gradually decrease bitrate until the fps gets back to 120 - might be a limitation of the encoding block, it may not be able to spit out the frames fast enough at high bitrate.

    This way you might identify the highest possible bitrate that still allows true 120 fps, and is still higher than 80 Mbps...

  2. 1 minute ago, hirsti said:

    I am a little confused, I did a recording at 160Mbits/sec, it shows in the info from Medianfo as being 160 Mbps, however if I run that MP4 through the Samsung converter the resulting file shows it as being 440 Mbps, why is this anyone?  Is it because you are going from H265 to H264

    General
    Complete name               : F:\RAW files should be on e drive\nx1hack\160mbit\SAM_0531.MP4
    Format                      : MPEG-4
    Format                      : HEVC

    After Conversion

    General
    Complete name               : F:\RAW files should be on e drive\nx1hack\160mbit\conv\SAM_0531_Pro_4096x2160.mp4
    Format                      : MPEG-4
    Format                      : AVC

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

  3. 49 minutes ago, hirsti said:

    I have 2 SD cards that I have tested on, a Sandisk 280 MB/s and a Lexar 2000x 300 MB/s
    On the sandisk it is reliable setting the bitrate @ 160 MB/s, if you step up to 200 it will fail after about 10 seconds.
    On the Lexar it is reliable setting the bitrate @ 200 MB/s, if you step above this then it fails.

     

    1. read this: http://www.magiclantern.fm/forum/index.php?topic=5827.25

    2. read this too: http://www.magiclantern.fm/forum/index.php?topic=6278.0

    3. format (in your PC) the SD card with larger block sizes

    4. test

    /done exfat test

    5. If you are a Windows [the horror, the horror, I pity you] user, either go here: http://www.ext2fsd.com/ or here: http://www.paragon-drivers.com/extfs-windows/ [if you like proprietary stuff]

    6. then format your SD card in ext4, without journal and with a largish block size (8192 or 16384)

    7. test again

    /done ext4 test

    8. report back here

    There, I just gave you a replacement for tonight's sleep :-), and therefore a chance to join me in missing sleep :-)

    rgds

    PS. I have high hopes for ext4 since it is a native Linux format whereas exfat is Microsoft and may well be implemented as a fuse filesystem which performs much much worse.

  4. 21 minutes ago, Pavel Mašek said:

    I have tried 320 / 250 /200 Mbits with fastest possible card (Lexar 2000x) and it records just few seconds and then it crash with quick "slow card" message (clip with 200Mbits was longer then with 320 Mbits). So it seems that 160 Mbits is only one stable bitrate for now. I would like to do more tests but do not have time for it. However - still GREAT achievement Vasile, thank you so much.

    I think someone needs to do some more in-depth tests. I do not know how the codec works but based on previous analyses (seen in this thread) of my fish tank video, the codec uses a variable rate. This is supported by @SMGJohn codec info screenshots.

    What this means is that the 160Mbit is not really the true rate, it is merely the target average rate for the codec, and that, based on the complexity of each frame, the codec will use less or more bits to encode it.

    It is likely that the codec uses something like this: target rate => [min_rate .. max_rate] where min_rate and max_rate are fixed multiples of target rate.

    For example (and this uses numbers coming from my hat): 160Mbit/s rate == in reality [0.5x160 .. 2x160] == [80 .. 320] Mbit/sec.

    This could be easily be proved with your Lexar card by recording a static scene vs a dynamic scene - the static scene should allow higher bitrates (presumably because it would hover near the lower limit) before the crash.

  5. http://***URL removed***/forums/post/57461650

    By the way, I'd like to ask you all to NOT name the bitrate and let everyone download the file if they want to know it.

    It would be an interesting thing to see how long you can keep it under wraps and only discuss "around it" but without naming it explicitly.

    I have no way to enforce this [oops, I just realized I do :-) and you know it too] but I do ask you to play by this rule, at least until I am back.

     

  6. 7 hours ago, Chant said:

    Some interesting tidbits found tonight. 

    "setpath    0 - 2(0:OTF/1:IPCout/2:RawOut/3:Ldc Out/4:120FPS OTF/5:120FPS IPC out
            6:120FPS Raw Out/7:120FPS Ldc Out/8:panorama/9:MFZoom)"
    "sensorframerate    12,15,20,24,25,30,40,50,60,100,120,240
            outputframerate    12,15,20,24,25,30,40,50,60,100,120,240
    dataframerate      12,15,20,24,25,30,40,50,60,100,120,240"

    Still looking for the encoder though. To confirm srp or other hardware. But the closer it gets. And then the real fun happens!

    I can look into the nx500 firmware deeper after I do the nx1 and see what can be added or changed. I do have a want for a nx500 b cam, especially as a gopro stand in due to them being cheaper! Make everyone want this samsung gear now that they cant get them. Maybe it was samsungs plan all along.

    Edit

    "HEVC Encoder
    %s:%s(%d)> Width(%d) or height(%d) is not multiple of 8
    %s:%s(%d)> HEVC[%d] Cfg WH %dx%d %d, BR:%dkbps GOP:%d > size 0x%x > return %d"

    the full sensor read out should be possible with this also notice gop setting and bit rate.

     

    I will have to look at the encoder.cpp file which is where things get more complicated but this is very good news.

    Please let me know if you want the NX1 and NX500 encoder and decoder .bin files. They are separate files stored in the file system and dynamically loaded to the SoC when needed.

  7. 1 hour ago, SMGJohn said:

    What does these two settings do?

    [113]| USERDATA_RAW_PACK             | RAW_PACK_PACK                 |0x00710000| 7405568|
    [114]| USERDATA_RAWQUALITY           | RAWQUALITY_LOSSLESS           |0x00720000| 7471104|

    Will it enable me to spit out lossless RAW photos? 

    I always wanted to see what the NX1 would do with lossless raw images because I noticed blacks gets crushed on the extreme end and it looks more like compression artefacts than something the camera would not be able to capture.

    Looks pretty self-explanatory to me... and the NX1 manual (nor menus) does not offer a choice.

    What you see above simply confirms that NX raw files are losslessly compressed.

  8. 2 hours ago, Pavel Mašek said:

    That would be great! But everyone here would probably appreciate if you would have more than 100 years :-D  (say 150Mbps would be nice).  But I understand, that was just an example.... 

    a perfect example of being content with what one is given (or not being demanding).

    If this goes on I will consider lowering the target bitrate...

    :-)

  9. 7 minutes ago, MountneerMan said:

    What else is in this DEV menu?

    Care to take some screen shots and upload?

    Quite a few things and some of them downright dangerous.

    I think I will let others post / discuss them [they are visible to anyone with a camera, no skill required to get to them], for the moment I prefer to concentrate on the word "bitrate" rather than on "screenshot" - if you get my drift :-)

  10. On 13/03/2016 at 11:08 AM, Syme said:

    Has anyone actually found where and how the SRP is used in the NX1 firmware? It would be a shame to spend a bunch of time learning how it is programmed only to find out that it's just something like an audio processor as in the Exynos SoCs the DRIMe-5 is based on. Seems to me like there's a pretty good chance Samsung just used the fast dedicated 4k HEVC encoder they were already developing for their cell phones. Their video encoders are famous for their efficiency, so if they were done with the design of their HEVC codec in time the smart choice would be to use less flexible hardware for the sake of battery life and heat.

    I really hope it is being used for video encoding, since that would open the door to much more significant modifications (with a massive reverse-engineering and digital design effort). However I think the prudent first step is to figure out exactly what all it is doing in the camera. That's what I will be attempting to do once I have some time.

    not sure if that is the srp compiled code but I'd say yes with 80+% probability.

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

     

  11. On 12/03/2016 at 11:22 AM, Chant said:

    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.

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

    Please let me know if you want the NX1 and NX500 encoder and decoder .bin files.

×
×
  • Create New...