MLV Lite

[dmilligan]

Confirmed wrong black level, black level in file: 6758, should be: 2048, see this thread: http://www.magiclantern.fm/forum/index.php?topic=11664

Note: exiftool wouldn't write to this file for some reason so I had to use a hex editor to change the black level manually

This is an existing problem with the raw backend (which still hasn't been fixed after almost 2 years!), and isn't specific to MLV Lite.

[a1ex]

Black level fix available in current nightlies.

For testers - I'm trying to squeeze the last bit of performance out of MLV Lite, to make it as fast as (or maybe faster than) the original raw_rec. Here's where you can help: http://www.magiclantern.fm/forum/index.php?topic=17091.0

[platu]

Just tried the latest MLV Lite build on my 5D3 and the speed does seem comparable to the last nightly.  I've long wished to be able to use the extra features of MLV, but like some others, felt the performance tradeoff was an issue.

Also, as others have reported, I too am not able to use MLraw Viewer with MLV Lite files.  I just get a black screen.  I realize that MLraw Viewer is no longer being updated by the original developer, but for me, it is still the fastest way to work with ML raw files.  It has become quite an important piece of my workflow.  While I love the idea of consolidating the .raw and .mlv formats, it would be difficult to lose the real-time previews, exposure, white balance adjustments, and lut/log output of MLraw Viewer in exchange for this.  Not trying to complain, just pointing out something that may effect others who also have come to depend on MLraw Viewer as part of their workflow.

Regardless, good job to all the involved devs in refining the standard for ML raw.  Your work is very much appreciated.

[DeafEyeJedi]

and what's wrong with MLVFS + DR12 for quick previews @platu?

[a1ex]

And what's wrong with figuring out why the files don't open in MlRawViewer? I've tried both apps, and it doesn't look like MLVFS is a complete replacement for MlRawViewer.

The point of MLV Lite is not to break compatibility with existing apps. I don't know yet who is to blame - if it's MlRawViewer, we should fix that (hint: it's open source); if it's MLV Lite creating slightly incorrect files (not fully compliant with the spec), we should fix that.

[Licaon_Kter]

And what's wrong with figuring out why the files don't open in MlRawViewer?

I keep recommending MSVFS to users that keep popping on the MLRAWViewer thread with issues, since it's not developed anymore maybe MLVFS already has their use case covered.
Nothing is wrong with MLVRawViewer, when it works, and if someone can fix it, the better.

[dmilligan]

Workaround: use MLVFS and MLRawViewer together (MLRawViewer is capable of playing back DNG files).

[a1ex]

During my experiments, I've encountered a MLV that caused the Lua parser to go into an infinite loop. Its size is exactly 4294967295 bytes, it was not followed by any M00 file, and the card still had over 7GB free. There were other M00 files on the card recorded before it, so I guess file_size_limit was 1.

mlv_dump -v:

Code: [Select]

MLV Dumper v1.0
-----------------

Mode of operation:
   - Input MLV file: 'M20-1519.MLV'
   - Verbose messages
   - Verify file structure
   - Dump all block information
File M20-1519.MLV opened
File M20-1519.M00 not existing.
Processing...
File Header (MLVI)
    Size        : 0x00000034
    Ver         : v2.0
    GUID        : 10587574007593374301
    FPS         : 29.970000
    File        : 0 / 0
    Frames Video: 0
    Frames Audio: 0
Block: RAWI
  Offset: 0x00000034
    Size: 180
    Time: 0.791000 ms
    Res:  1920x1080
    raw_info:
      api_version      0x00000001
      height           1318
      width            2080
      pitch            3640
      frame_size       0x00493450
      bits_per_pixel   14
      black_level      2046
      white_level      15000
      active_area.y1   28
      active_area.x1   146
      active_area.y2   1318
      active_area.x2   2078
      exposure_bias    0, 0
      cfa_pattern      0x02010100
      calibration_ill  1
Block: IDNT
  Offset: 0x000000e8
    Size: 84
    Time: 0.804000 ms
     Camera Name:   'Canon EOS 5D Mark III'
     Camera Serial: 'B052G52X3'
     Camera Model:  0x80000285
Block: EXPO
  Offset: 0x0000013c
    Size: 40
    Time: 0.835000 ms
     ISO Mode:   0
     ISO:        800
     ISO Analog: 96
     ISO DGain:  0/1024 EV
     Shutter:    29994 microseconds (1/33.34)
Block: LENS
  Offset: 0x00000164
    Size: 96
    Time: 1.190000 ms
     Name:        'EF-S24mm f/2.8 STM'
     Serial:      ''
     Focal Len:   24 mm
     Focus Dist:  65535 mm
     Aperture:    f/4.00
     IS Mode:     0
     AF Mode:     3
     Lens ID:     0x0000003A
     Flags:       0x00000000
Block: RTCI
  Offset: 0x000001c4
    Size: 44
    Time: 1.207000 ms
     Date:        20.04.2016
     Time:        15:19:25 (GMT+0)
     Zone:        ''
     Day of week: 3
     Day of year: 110
     Daylight s.: 0
Block: WBAL
  Offset: 0x000001f0
    Size: 44
    Time: 4.029000 ms
     Mode:   9
     Kelvin:   6400
     Gain R:   1024
     Gain G:   1024
     Gain B:   1024
     Shift GM:   0
     Shift BA:   0
Block: NULL
  Offset: 0x0000021c
    Size: 484
    Time: 47594302144599.398438 ms
Block: VIDF
  Offset: 0x00000400
    Size: 3629056
    Time: 1471.736000 ms
   Frame: #0000
    Crop: 152x132
     Pan: 146x133
   Space: 32
Block: VIDF
  Offset: 0x00376400
    Size: 3629056
    Time: 1505.470000 ms
   Frame: #0001
    Crop: 152x132
     Pan: 146x133
   Space: 32
Block: VIDF
  Offset: 0x006ec400
    Size: 3629056
    Time: 1538.806000 ms
   Frame: #0002
    Crop: 152x132
     Pan: 146x133
   Space: 32

[...]

Block: VIDF
  Offset: 0xffad4400
    Size: 3629056
    Time: 40911.497000 ms
   Frame: #1182
    Crop: 152x132
     Pan: 146x133
   Space: 32
Block: VIDF
  Offset: 0xffe4a400
    Size: 3629056
    Time: 40944.810000 ms
   Frame: #1183
    Crop: 152x132
     Pan: 146x133
   Space: 32
Block: [unreadable characters]
  Offset: 0xffe4a420
    Size: 32
    Time: 4504149383184.391602 ms
Unknown Block: , skipping
[ERROR] Invalid block size at position 0xffe4a440
Processed 1184 video frames
Done

Files before the affected one:

Code: [Select]

A:/DCIM/100EOS5D/M20-1512.MLV:  602 frames, 2.034653 GB
A:/DCIM/100EOS5D/M20-1513.MLV:  911 frames, 3.079018 GB
A:/DCIM/100EOS5D/M20-1514.MLV:  909 frames, 3.072258 GB
A:/DCIM/100EOS5D/M20-1515.MLV: 1160 frames, 3.920594 GB
A:/DCIM/100EOS5D/M20-1516.M00: 1257 frames, 4.260247 GB -- note: it prints the last chunk and the total size
A:/DCIM/100EOS5D/M20-1517.M00: 1442 frames, 4.873704 GB
A:/DCIM/100EOS5D/M20-1518.MLV:  744 frames, 2.514588 GB

I've got it with b658401, only once in several hours of running the benchmarking script. Also worth mentioning that older versions of MLV Lite didn't manage to reach 4GB at my test settings.

edit: pushed some changes that will hopefully fix this issue (and other similar issues regarding file spanning).

[kidfob]

@DeafEye, I sent you a PM. Did you get it? Thanks

[DeafEyeJedi]

And what's wrong with figuring out why the files don't open in MlRawViewer? I've tried both apps, and it doesn't look like MLVFS is a complete replacement for MlRawViewer.

The point of MLV Lite is not to break compatibility with existing apps. I don't know yet who is to blame - if it's MlRawViewer, we should fix that (hint: it's open source); if it's MLV Lite creating slightly incorrect files (not fully compliant with the spec), we should fix that.

Agreed. But to me I save more time by using MLVFS instead of running MLRV (don't get me wrong I still use this wonderful previewer) but rather than complaining that it doesn't work (yet) I figured I could share my opinion. I'm all for the header fix which will eventually happen sooner rather than later! 

Workaround: use MLVFS and MLRawViewer together (MLRawViewer is capable of playing back DNG files).

That's right. Good point though similar workflow can still be achieved together w DR12 since it plays back in realtime!

@DeafEye, I sent you a PM. Did you get it? Thanks

Had to dig through my massive PM's that I get on weekly basis and managed to find your PM ... Thanks for the reminder and will report back when I can!

[platu]

and what's wrong with MLVFS + DR12 for quick previews @platu?

No doubt that MLVFS is amazing.  But there are just some things that MLRaw Viewer does that I prefer in my workflow.  It's not just quick previews.  As I said in my previous post, I'm not complaining.  Just adding my observation that MLV lite is not compatible with it.

[a1ex]

+1. I didn't see it as complaining, and we should not discourage this kind of reports.

[DeafEyeJedi]

You're right @platu and my assumptions were incorrect while I meant no discouragement and please continue your observations as we obviously value them. Hopefully MLRV would work w mlv_lite files sooner rather than later.

[platu]

Workaround: use MLVFS and MLRawViewer together (MLRawViewer is capable of playing back DNG files).

I had already found this suggestion in a previous post but I still appreciate the tip.  I do happen to use MLraw Viewer for more than just previews.  For example, all exporting (DNG or MOV) does not work (at least for me) when viewed through MLVFS.  I realize that one of the main points of using MLVFS is to eliminate the need for doing this, but there are scenarios where some might prefer the workflow of baking white balance, luts, etc into a MOV for both space savings (deleting the orig mlvs) as well as sharing with other systems not equipped to handle ML Raw.   That said, what you achieved with MLVFS is pretty incredible and although I'm just in the testing stage with it, I can see using it in much of my future workflow.

[platu]

@DeafEyeJedi, No worries... I'm not easily discouraged anyway

[johannsebastianbach]

The solution with previewing MLV's with MlRawViewer trough MLVFS was promising at first, but turned out to have problems.

Problem 1: With MlRawViewer before even my older macs could preview in realtime. Since you have to go around with MLVFS it doubles the CPU workload and unfortunately the cpu is not enough. It is still kinda possible, but I get stutter.

Problem 2: MlRawViewer creates its own files during first playback. When using MLVFS these files somehow are incompatible with the Smart Import 2 AE workflow, so you have to erase all MlRawViewer files first and if you want to preview MLV's with MlRawViewer again, you have to think of erasing them afterwards too.

About DR12: Also way too heavy for my old mac.

[Danne]

Could it be as trivial as mlv_lite doesn,t report amount of frames? 

[Danne]

Bouncyball just confirmed this regarding MlvRawViewer.

Could it be as trivial as mlv_lite doesn,t report amount of frames?

http://www.magiclantern.fm/forum/index.php?topic=17185.msg166559#msg166559

[DeafEyeJedi]

Nice work @Danne ... at least it seems we are heading towards on the right path.

Thanks for your kind contributions @bouncyball!

[keepersdungeon]

This is excellent! I saw that @A1ex was working on another version as well.
Got a bit confused though which one to use. Is anyone of these included in the nightly built? Or should I add it manually.
If I understood well does it mean we can rec more frames and go up with the resolution a bit more?

[THEMESSIAH]

Long time user of magic lantern on the canon 70d.. First time poster. I'm currently using it on my 5d mark ii... Great work by the way guys. My main workflow is fine, but when I tried using MLV Lite, I get black screen when previewing on MLRawviewer.. Not being able to preview is like an arrow in the heart. Please help me or point me in the right direction. I've read to change the headers but "how" do I change it. Any help would be appreciated. 1872x1044 almost continuous I haven't let it run out.. Very impressive! I'm happy.. thanks

[Danne]

I encountered a bug with mlv_lite today when trying to work with dark frames. In short it seems to be a mismatch in how frame sizes are produced going through darkframe subtraction in mlv_dump. After filming and creating a darkframe this error message appears when running the averaged darkframe with the footage. Error message occurs even though files are filmed with exactly the same settings in cam.

Code: [Select]

Processing...
[ERROR] Error: Frame sizes of footage and subtract frame differ (1494976, 1494720)Processed 0 video frames
Done
command in test with averaged darkframe.

Code: [Select]

mlv_dump -o a_M20-1342.MLV -s avg_EOSM_res_1728x692_iso_400_fps_24.002000.MLV M20-1342.MLV
Test files here(shortened)
https://bitbucket.org/Dannephoto/magic-lantern/downloads/darkframe_mlv_lite_issue.zip

Bypassing the break in the error message will create fine darkframes but that won,t change the mismatch issue of course.

[a1ex]

Looking into it.

Are you sure it's a performance issue?

[Danne]

Performance is zero since processing breaks, but when working this has nothing to do with performance, you,re right. Maybe should have posted this in some other thread or maybe over at bitbucket.
Sidenote.
Seems to be an issue with flatframe processing as well. Have a few more tests to do.
*yes, flatframe processing takes a hit as well.

[a1ex]

Pushed a fix to mlv_dump.

The files were all valid, so it's not a bug in mlv_lite. What happened: a VIDF block in mlv_lite may include some padding after the actual image data, to write multiples of 512 bytes. Currently, mlv_rec files do not include any padding. The dark frame does not include any spacing or padding. And, when comparing the frame sizes, mlv_dump didn't discard the padding data, resulting in false error message.