Magic Lantern (RAW) Video format v2.0 (mlv_rec.mo)

[DeafEyeJedi]

...does the dark frame really make so much difference?

Absolutely it does... Kudos to @Danne for pointing this out and thanks to you @g3gg0 for your never ending magic!

Pre-DF 5D3 @ ISO 3200


Post-DF 5D3 @ ISO 3200


Pre-DF 7D @ ISO 3200


Post-DF 7D @ ISO 3200


Pre-DF 7D @ ISO 6400


Post-DF 7D @ ISO 6400


Pre-DF 7D @ ISO 6400 (200% zoomed in ACR)


Post-DF 7D @ ISO 6400 (200% zoomed in ACR)


Flickr link to DF Avg Comparisons Album: https://flic.kr/s/aHskMcV8d2

All files were processed with cr2hdr.app (latest mlv_dump included) Thanks @Danne & @g3gg0!

[ShootMeAlready]

mlv_dump command line examples for Windows??? Cant find any???

I am trying to process a 10bit raw video to dng

Here is what I enter (with mlv_dump in directory)
G:\DCIM\100CANON>mlv_dump -o test02 -b 10 --dng m20-1339.mlv


PROBLEM: The output states its defaulting to 14bpp not 10??? when I try with default it still reports 14 bpp
The picture is too small as file properties reports 128x94 96dpi, this is wrong it should be 1824x776

It seems the command-line is wrong
 
Blow is Windows 10 output:

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

Mode of operation:
   - Input MLV file: 'm20-1339.mlv'
   - Enforcing 14bpp for DNG output
   - Convert to DNG frames
   - Output into 'test02'
File m20-1339.mlv opened
File m20-1339.m00 not existing.
File m20-1339.IDX opened (XREF)
XREF table contains 328 entries
Processing...
Cold pixels : 0
Reached end of all files after 328 blocks
Processed 304 video frames
Done

[g3gg0]

the DNG code only supports 14bpp, so the DNG will be saved as 14bpp DNG.

thus the "- Enforcing 14bpp for DNG output"

[Danne]

I,ve been having issues with chroma smoothing in mlv_dump. It,s always occurring in and around blown highlights. Doesn,t matter if shooting 10/12/14bit. When trying to understand what is going on I,m checking chroma_smooth.c it seems the calculations around green is what causes it. So I check against MLVFS and although it seems to be using the same chroma smooth code the output is free from corruption. Could it be related to focus pixels? Maybe those pixels needs to be handled before applying chroma smooth? The good thing about cs2x2 is that when it works it almost completely removes focus pixels. WIth darkframe subtraction it completely removes all focus pixels.

MLV file
https://bitbucket.org/Dannephoto/magic-lantern/downloads/broken_cs2x2.MLV
DNG file
https://bitbucket.org/Dannephoto/magic-lantern/downloads/broken_cs2x2.dng

Chroma smooth set to cs2x2

Examples

[a1ex]

raw2dng appears to handle it properly.

Code: [Select]

mlv_dump --dng --no-stripes --no-fixcp broken_cs2x2.MLV
dng2raw broken_cs2x2_000002.dng
wine raw2dng_cs2x2_whitefix.exe broken_cs2x2_000002.RAW


[Danne]

I was just thinking it might be caused by vertical stripes and now see your settings. Didn,t run with vert stripes off before.
Gonna check later.

[Danne]

Code: [Select]

raw2dng appears to handle it properly.
Ok, mlv_dump produce corrupt chroma smoothing in highlights. Just tested with disabling vertical stripes and no pixels. Then tried converting the file to legacy RAW. How do I even apply cs2x2? Don,t seem to be automated so can,t check this but I take it raw2dng and chroma smooting is working as it should according to a1ex. Any ideas about what,s up with mlv_dump?

I got raw2dng chroma smooth to work and that code is working good with blown highlights. Not mlv_dump.
#define CHROMA_SMOOTH

Copy paste raw2dng chroma smooth void code into mlv_dump works so there is something fishy going on with chroma_smooth.c probably.

[a1ex]

Looks like mlv_dump borrowed the chroma smoothing from cr2hdr (which was fine-tuned a long time ago to reduce color artifacts, including those near clipping point), rather than raw2dng (which was fine-tuned for focus dots and had fixes related to white level and shadow noise). Worth checking whether the two codes can be unified.

[Danne]

Yes, that would be nice. I have put in raw2dng code for the time being in mlv_dump and it works very good. What,s your take on this @g3gg0?

[GutterPump]

I noticed something strange when i want read my DNG sequence with audio into Davinci Resolve 12.5.

When extract with mlv_dump, the .wav file isnt combined with the DNG sequence.

There is no issue when it's done with mlvfs.

 

Is there something to change about the output file name command ?
 Actually, in my folders from mlv_dump it look like this :
 

And my command line :

Code: [Select]

@echo off
for %%a in (*.MLV) do ( md "%%~na" 2>nul )&(mlv_dump.exe -o %%~na\%%~na --dng %%~na.MLV )

[Danne]

Wav file needs certain metadata. It,s also working in cr2hdr.app and MLP.(thanks to dmilligan)

[GutterPump]

Thanks for this detail Danne.

How can we change the mlv_dump code for doing the same job of mlvfs about this issue ?

The code from Dmilligan for sync audio in Resolve is here but I am completely incompetent to integrate it in mlv_dump.

[Danne]

Are you on windows? Otherwise the other programs would work. The audio file needs to match amount of dng frames. At least cannot be longer. Second a template metadata which must match frames per second in the dng file. I do this with bwf meta edit to put in ixml info and shorten audio with ffmpeg. Both programs exists for windows if you don,t want to do it in c-code.
It,s mainly row 32-50 that needs to be put into the wav file. Framerate must be in 5 numbers(e.g 24fps will be 24000, 23.97 will be 23970)
https://bitbucket.org/dmilligan/mlvfs/src/9f8191808407bb49112b9ab14c27053ae5022749/mlvfs/wav.c?at=master&fileviewer=file-view-default

Bwfmetaedit
http://bwfmetaedit.sourceforge.net/

[dfort]

@g3gg0

Is is possible to add some sort of an optional extensible block to the MLV specifications? I'm not sure what the progress is on the Extended LENS block, ELNS, that you proposed on the Assign lens focal length and name for non cpu lenses topic but since it seems possible to add blocks without breaking current MLV applications perhaps a general extensible block (xml type of thinking here) would be possible?

A good example of this would be for the crop_rec module. That module could add the crop_rec options used and applications like MLVFS, MLVProducer and Danne's apps that uses my focus pixel script can use that information to pick the right pattern to map out the focus pixels.

I'm not sure the best way to set up such a block. Here's an idea with three optional fields using xml style tags:

Code: [Select]

Block: XBLK
  Offset: 0x00000168
    Size: 52
    Time: 1743.839000 ms
     option_1:   <crop_rec>CROP_PRESET_3x3_1X</crop_rec>
     option_2:
     option_3:

Maybe just one field would be necessary with xml style tags and perhaps using tags isn't the best solution but you get the idea. Something so that when a new feature is introduced it won't need a new block added to the MLV specification.

[Danne]

First we need mlv_rec to tell us we are using crop_rec right @dfort? (Realize now that is what you meant already)
And yes! Metadata for wonderful crop_rec module needed.

[dfort]

My understanding of how this works is that in order to have mlv_rec tell us we're using crop_rec it will require adding a field for that information. Instead of doing something specifically for crop_rec I'm proposing adding a block that won't need to be updated every time a new feature is added.

I don't know how it should be coded but basically crop_rec would pass the preset used to mlv_rec and it would be saved in the extended block.

Let's say there is some other module that uses rather specific information like in the case of astrophotography saving the sensor temperature in the MLV header so that as the DNG's are being processed it can automatically pick from a library of dark frames saved at various temperatures. Instead of having to add this to the MLV specification, which probably won't happen, this can be added to the XBLK section.

Just an idea.

[a1ex]

FYI: http://www.magiclantern.fm/forum/index.php?topic=17021.msg173941#msg173941

That way, communication between crop_rec and mlv_rec would be done through the raw backend.

[dfort]

Ok, I see.

For MLV files, we could add a new block (CROP) with exactly the same structure.

It still needs a new block that isn't in the current or proposed MLV specifications. I was throwing out an idea that would account for future needs.

[g3gg0]

previously i already implemented some stuff locally.
polished it and pushed it into branch mlv_rec_callbacks

also modified dual_iso and mlv_snd to add support.
just wondering if there is a way (or need anymore) to tell which lines (odd/even) are DISO'd ?
so i would simply change the definition to just put the "enabled" flag there as it is now.


interface:
any module can register its need for being called via mlv_rec_register_cbr(uint32_t event, event_cbr_t cbr, void *ctx) like this:

Code: [Select]

    /* register callbacks */
    mlv_rec_register_cbr(MLV_REC_EVENT_STARTING, &mlv_snd_cbr_starting, NULL);
    mlv_rec_register_cbr(MLV_REC_EVENT_STARTED, &mlv_snd_cbr_started, NULL);
    mlv_rec_register_cbr(MLV_REC_EVENT_STOPPING, &mlv_snd_cbr_stopping, NULL);
    mlv_rec_register_cbr(MLV_REC_EVENT_BLOCK, &mlv_snd_cbr_mlv_block, NULL);
or

Code: [Select]

    mlv_rec_register_cbr(MLV_REC_EVENT_STARTED | MLV_REC_EVENT_CYCLIC, &isoless_mlv_rec_cbr, NULL);

those callback functions will get called for every registered event that gets fired.

so simply register your module's cbr. it gets called and you can queue your custom block like below.

Code: [Select]

void isoless_mlv_rec_cbr (uint32_t event, void *ctx, mlv_hdr_t *hdr)
{
    static mlv_diso_hdr_t dual_iso_block;
   
    mlv_set_type((mlv_hdr_t *)&dual_iso_block, "DISO");
    dual_iso_block.blockSize = sizeof(dual_iso_block);
    dual_iso_block.dualMode = dual_iso_is_active();
    dual_iso_block.isoValue = isoless_recovery_iso;
   
    mlv_rec_queue_block((mlv_hdr_t *)&dual_iso_block);
}

in this case 'mlv_diso_hdr_t' is already defined by mlv.h but you can define any type as long it implements 'mlv_hdr_t'

Code: [Select]

typedef struct {
    uint8_t     blockType[4];
    uint32_t    blockSize;
    uint64_t    timestamp;
} mlv_hdr_t;

so e.g. add this to crop_rec:

Code: [Select]

typedef struct {
    mlv_hdr_t  header; /* cleaner to embed default header instead of explicitly defining members */
    uint8_t    profileName[32];
} crop_rec_hdr_t;

and fill that block on record start.

[a1ex]

There is a generic callback interface in ml-cbr.c (you merged it a while ago). Could it be useful?

[g3gg0]

good point. i totally forgot about this.
though it might be a bit slow for e.g. block callback when there are more registered clients.

[k2121]

Hi,
I'm new user of ml.
Why when I activate "raw video (mlv)" option, everyday I have another expect write speed? It's annoying, because I never know when I can record MLV continously. Please help me.
Greetings
K.

[KMikhail]

Hey guys!

Couldn't notice how much cleaner the previews of dark frame usage are. However, I'd say the whole process might be substantially improved: if only we could generate a 'book' of dark frames and, during conversion of the MLV to dng's or transcoding, an appropriate ISO/Shutter/FPS frame would be selected. The 'book' could be fairly easily generated from a continuous MLV file, where Shutter time and ISO are swept manually, let's say once in a second, or (wonderfully) generated automatically by a plug-in in camera.

I have plenty of MLV files, with ISOs all over the place (even real time changed). See my point? I'm sure I'm not alone. Plus, on top of it - I used different FPS. A tag "Dark Frame was already applied", might have a useful potential as well. Though, I'd definitely prefer to apply it to mlv and forget about it.

Surely, some of the permutations might be excessive (like fps) and at times I also was recording into modes different from an uncropped FullHD (sadly).

If the 'book' is too much to ask, then, during generation of black frame mlv's, mlv_dump can average frames into diff files, based on ISO and shutter time. Would be sweet as well!

P.S. Am I correct and MLRawViewer (1.4.3) doesn't support compressed mlv's?

Thanks for the great work!
Mikhail

[DeafEyeJedi]

Re: generating a 'book' or a storage folder full of DF files is already possible in conjunction w @Danne's latest and greatest cr2hdr.app or better yet the recent morphed mlv-dump_steroids!

[a1ex]

A proposal for recording pixel binning / line skipping parameters and other related information:

http://www.magiclantern.fm/forum/index.php?topic=17021.msg181639#msg181639