MLV Lite

[Danne]

Interesting. So either solution then?
1 - reliable NULL clean up
2 - alter mlv_dump warning routine and keep on processing
3 - renaming routine which will process renamed spanned files with extension MLV(easily done with MLP)

Question. In MLVFS you managed to disregard this vidf issue since the show up fine in there but gives the problem with mlv_dump?

[Ottoga]

@Dmilligan

Great explaination for what is happening in the file structure.

From my testing,  the common activity that the working tools e.g.: MLVFS and MLVP have is...

They prebuild an index file that is used to access the individual frames.

Unless it is building it in ram, mlv_dump doesn't seem to do this.

Might be another option to consider if changes are needed for mlv_dump.

[dmilligan]

Interesting. So either solution then?
1 - reliable NULL clean up
2 - alter mlv_dump warning routine and keep on processing
3 - renaming routine which will process renamed spanned files with extension MLV(easily done with MLP)

I think the solution is probably 1 AND 2.

There could be other reasons besides this one that mlv_dump should continue if at all possible and not error out when it encounters some invalid data like this (e.g. in the case of data corruption). It might actually be best to have this as a command line parameter (e.g. --strict), b/c mlv_dump is useful for devs validating that the MLV files they are producing are completely valid.

Then also, mlv lite should try its best to output valid files, and not count on converters being able to handle invalid data.

I figure out where to put the NULL by seeking backwards from the end of the file using FIO_SeekSkipFile, perhaps the behavior of doing this is not standard. There are potential other ways, so we will just have to try them. I'll post some builds later on. Can you search for the string "NULL" (without quotes) in the MLV file using a hex editor? Maybe it's there, just in the wrong place.

Question. In MLVFS you managed to disregard this vidf issue since the show up fine in there but gives the problem with mlv_dump?

The reason MLVFS works is that it is simply not as strict about validating all the data before trying to use it, and because the frame exists in the next chunk, it ends up never trying to load the VIDF chunk that is cut off. If you delete the .IDX and remove the .M00, M01, etc. leaving only the MLV, I bet MLVFS will either: crash, give you an error, or show part of the last frame as garbage.

[dfort]

I ran a test just to answer one of the most annoying noob question, "How long can camera X record 1920x1080 raw video?" Of course camera X is usually anything other than a 5D3 so I grabbed the 700D I've been using for focus pixel testing and here are the results:

MLV Lite

MLV

The camera was set at 5x zoom mode, 1920x1080, 23.973 fps override and Global Draw off for all tests. Each test was run 10 times. The same card was used but the MLV Lite test was compiled from the new-raw-format branch and the MLV test from the mlv-prop-data branch (needed for focus pixel fixing--hint hint).

Just for the sake of comparison I also ran a test with the raw format that MLV Lite is proposed to replace.

The results:

RAW Format	Mode (value that appears most often in a set of data)
MLV Lite	63 frames
MLV	66 frames
Raw	71 frames

Don't read too much into this test, the results are really very close at just a little under 3 seconds of recording time. Not very practical. The bottle neck of course is the SD card controller. If there could only be the slightest bit of compression--but that is just wishful thinking.

One thing that may be a problem is that the fps override was set to 23.98 but all the files, including the raw test, came out at 24.028 fps. So there's something strange going on with FPS override.

Another problem is that the EXIF metadata on the DNG files doesn't display the camera information properly. Except for the ones shot with the mlv-prop-data branch and processed with MLVFS as reported by exiftool:

Code Select Expand

Unique Camera Model             : Canon EOS REBEL T5i


But this is what it looks like when that same MLV file is processed with mlv_dump --dng:

Code Select Expand

Make                            : Canon
Camera Model Name               : Canon EOS REBEL T5i
Unique Camera Model             : Canon EOS 650D


The camera identity crises doesn't end there. From the 700D raw test here's a raw2dng converted DNG:

Code Select Expand

Make                            : Canon
Camera Model Name               : Canikon
Unique Camera Model             : Canon EOS M


[EDIT]: Oops--it is a little more complicated that this. The RAW file was process by raw2dng using MLP which adds the camera information. In this case it is obviously incorrect. The is what happens when using raw2dng by itself:

Code Select Expand

Make                            : Canon
Camera Model Name               : Canikon
Unique Camera Model             : Canikon

This is actually what I expected to see--no metadata saved in this early version of raw video.

[dmilligan]

I think I fixed the spanning issue. New version uploaded:
https://bitbucket.org/dmilligan/magic-lantern/downloads/raw_rec.mo

[Danne]

Yes! Working!
Ran three recordings. 5D mark III, firmware 1.1.3. The biggest consisting of 5 chunks around 7000 files. Amount matched exactly in MLVFS and coming from mlv_dump. Great work.
Will find time to run some allround testing. Still can,t produce any corrupted frames. Great! Been testing with 25 fps and focus peaking on 1920x1080. Very promising.

[Ottoga]

@dmilligan

A promising result from Dane.  Will rerun tests on my 7d when I get back home (2 days).

[Danne]

Some more tests. Read them with the usual grain of salt. Formatted my cf card and warmed it up before testing. 5D mark III 1.1.3

mlv_lite
31 s
1920x1080 FPS 29.976 Preview auto
mlv(regular)
8 s
1920x1080 FPS 29.976 Preview auto
RAW
43 s
1920x1080 FPS 29.976 Preview auto

mlv_lite
continuous
1920x1080 FPS 29.976 hacked preview
mlv(regular)
21 s
1920x1080 FPS 29.976 hacked preview
RAW
continuous
1920x1080 FPS 29.976 hacked preview

mlv_lite
18 s
1920x648 FPS 48.030 preview auto
mlv(regular)
10 s
1920x648 FPS 48.030 preview auto
RAW
23 s
1920x648 FPS 48.030 preview auto

mlv_lite
50 s
1920x648 FPS 48.030 preview hacked
mlv(regular)
13 s
1920x648 FPS 48.030 preview hacked
RAW
1m 51s
1920x648 FPS 48.030 preview hacked


Seems RAW has a slight advantage still. RAW was also the last format I tested(card warmed up). It is not enough to keep it from using mlv_lite if you ask me. getting cam model white balance and fps are all essentials to the dng file. Talking about white balance. Is there anything stopping mlv_rec(or raw_rec, mlv_lite for that matter) from grabbing this metadata tag:
ex from a CR2 file
WB RGGB Levels As Shot          : 2036 1024 1024 1949
This tag seems to work for any white balance mode from auto to getting calculations altering wb shift in magenta, cyan, blue, green.
I noticed the mlv format grabs other tags for white balance but it will still leave more to wish for especially in auto modes.

[dfort]

What is "preview hacked" ? Seems like Danne is getting better performance with that.

Seeing that he is also getting longer recording with mlv-lite than mlv(regular) I thought that maybe the problem with my test was that I used the mlv-prop-data branch for the mlv(regular) files and the new-raw-format branch on the mlv-lite files. I ran the test again this time using the mlv-prop-data branch for all the formats, moving just the raw_rec.mo to the card to the card for mlv-lite. However, I got the same results. The mlv-lite test was the last so the card was warmed up giving it the advantage.

By the way, on commit 86c8d1b (revision 12955) the note is:

mlv_lite: also update the skip offsets every frame

Does that mean focus pixel fixing when using dynamic panning in 5x zoom mode is supported? I haven't run any tests on that yet.

[Danne]

Hacked preview freezes live view. It,s in the advanced section which is where you change recording frame sizes. Not very useful when you want to see what you film but hey, sometimes you just want to shoot from the hip  .

[SteveScout]

Thanks a lot for creating this modfication!! Runs smooth and without any problems for me. 5DMK III on 1.1.3, 25fps @FullHD,  filled a 64GB Komputerbay CG Card which would normally behave a bit bitchy and unstable in longer takes. Converted with MLVconverter from "Tonybeccar", even the long takes (3minutes and longer, up to 20 Gigabytes) were converted without any errors.

Will surely test more (30fps and stuff), but if it always behaves like today I´ll take it for a regular production and to see how well MLV"lite" does!

Thanks!!

[AWPStar]

MLV lite works with mlvp.

50D
1568*882*25
MLV - 1060 Frames
MLV Lite - 1187 Frames
RAW - 1245 Frames

File splitting: passed

Crop mode: 1982*1080*25
MLVLite - 197 Frames
MLV - 199 Frames

[dmilligan]

Does that mean focus pixel fixing when using dynamic panning in 5x zoom mode is supported? I haven't run any tests on that yet.

No. Not if the raw buffer itself moves. Only if the skip is moved around. There isn't anywhere stored what part of the sensor is being recorded when in zoom mode, and AFAIK, currently we can only approximately guess where it is anyway.

[Canon eos m]

I will test this MLV-lite module tonight both on the 5DM3 and EOSM and report. I am especially interested to realize the better capacity to harness the 3X zoom and the higher than 1920x1080 files sizes. Will also check to see if the file / frame corrupts if the card runs out of memory.

[CITY-U1001]

make 2000x1080 for 50D, its work in last Tragic Lantern 

[Canon eos m]

5Dm3 recording stops after 12 seconds in both 1856X1088 and 1920X1080 @ 25fps. Card computer bay 64GB 1000x.

Replaced the raw_rec.mo with your module.

Continuous in smaller frame sizes. Also, continuous in 3X @ 1600X900.

[dfort]

make 2000x1080 for 50D, its work in last Tragic Lantern 

Unless the 50D is different from all the other cameras 2000 isn't a valid horizontal resolution. It needs to be a multiple of 16 32 so you can get either 1984 or 2016. (Huh, interesting years but way off topic.)

Even though these resolutions are not on the menu you can get to them by highlighting Resolution (don't go into the next submenu) and pressing left and right on the joystick or button or wheel, not sure what you got on the 50D. Oh yeah, you have to be in 5x zoom mode to get to these higher resolutions.

Back on topic--all of these additional resolutions are available in MLV-Lite as well as regular MLV. In fact you have far more choices than the old RAW format.

[dmilligan]

It needs to be a multiple of 16

32

[dfort]

2016 - 1984 = Doh!

There you go exposing my math skills again. Updated my post.

[reddeercity]

No he right with the 50D , The clue is the "Tragic Lantern" Search it 

Ok back on topic , I did a more comprehensive test with MLV Lite module on my 5D2 with the updated raw_rec.mo
I use the latest Nightly Build plus I compared mlv lite to full mlv ( use 2 different nighty for full MLV , feb15/2014 &Feb13/2016) and used the Old Raw format for Oct24/2013.
All tests done on CF Lexar 32GB 1066x
MLV Lite:
1856x1004 @ 23.976 with GD (global draw)  enabled  - 1134 Frames
1856x1004 @ 23.976 with GD disabled - continuous until full (74.5MB/s write speed)
1856x1004 @ 23.976 with GD disabled + HDMI enabled (Ninja HDMI Hard Drive recorder connected) - 3215 Frames
1856x1044 @ 23.976 With GD enabled - 1089 Frames
1856x1044 @ 23.976 With GD disabled - 1662 Frames

3x Crop mode:
1920x1038 @ 23.976 with GD enabled - 1046 Frames (76.9 MB/s Write Speed)
1920x1038 @ 23.976 With GD disabled - 2354 Frames
1920x1076 @ 23.976 With GD enabled - 724 Frames
2048x930 @ 23.976   With GD disabled -  continuous until full (74.8 MB/s Write speed)
2048x1024 @23.976  With GD disabled - 1016 Frames

Full MLV (Feb13/2016 Nightly build):
1856x1004 @ 23.976 + audio With GD enabled fill rate "0" - 1317 Frames
1856x928   @ 23.976 + audio With GD enabled fill rate "0" + HDMI enabled (Ninja HDMI Hard Drive recorder connected) - 2776 Frames
1856x928   @ 23.976 + audio With GD enabled fill rate "0" - continuous until full

Full MLV (Feb15/2014 Nightly build) : This is build I use 99% of the time for work ( Yea multiple of 16) Work better on 5D mark 2
1856x928 @ 23.976 fill rate "0"  + audio  -  continuous until full
1856x928 @ 23.976 fill rate "0"  + audio (GD disables automatically on recording raw video) + HDMI enabled (Ninja HDMI Hard Drive recorder connected) -  continuous until full
1856x1004 @ 23.976 fill rate "0" + audio  -  1788 Frames
1856x1044 @ 23.976 fill rate"0" + audio  -  748 Frames
1872x936  @ 23.976 fill rate "0" + audio -    continuous until full
1872x936  @ 23.976 + audio fill rate "0" + HDMI enabled (Ninja HDMI Hard Drive recorder connected) - continuous until full
3xCrop Mode:
2048x872  @ 23.976 + audio fill rate "0" continuous until full

Raw Format .raw (Old Raw) **Note** GD is automatically disabled while Raw video records
1856x1004 @23.976 + HDMI enabled (Ninja HDMI Hard Drive recorder connected) (74.6MB/s Write speed ) - continuous until full
1856x1044 @ 23.976  (77.5MB/s Write speed) -  continuous until full
1872x1012 @ 23.976 (76 MB/s write Speed)   -  continuous until full
1872x1054 @ 23.976 (78MB/s write speed)   -  2492 Frames
1872x1248 @ 23.976 (94MB/s write speed)  -  265 Frames
1880x1016 @ 23.976 ( 76.6MB/s write speed) -  continuous until full
1880x1058 @ 23.976 (78.4 MB/s write speed) - 2300 Frames
1880x1250 @ 23.976 ( 95MB/s write speed)   -  246 Frames
3xCrop mode:
1920x1038 @ 23.976 (79.7 MB/s write speed) - continuous until full
2048x930 @ 23.976  (79.4 MB/s write speed) - continuous until full
2048x1024 @ 23.976 (82.0 MB/s write speed) -  1534 Frames
2152x978 @ 23.976 (81.6MB/s Write speed)  -  1220 Frames

Just for kicks I try a few @ 29.97 fps
1856x1004 @ 29.97 - 278 frames
1880x800 @29.97 (75MB/s write speed)       -    continuous until full 

So it seems there a little bit of a bottle neck between MLV Lite & Old Raw
Well these are my finding.
Plus Spanning files work also ,  no problems so far extracting .

[Ottoga]

Tested MLV-Lite again today to see if the current version of raw_rec.mo still generates errors when mounting in mlvfs.

I generated a variety of MLV_Lite generated files that included single/multi-chunk mlvs, auto stopped mlvs due to frame skipping and one crash mlv when it tried to switch from 5x to 10x whilst it was recording. it was 41degrees C in the shade today and I got my first ever camera overheat warning so rather than risk harming the camera, I didn't test to see what happens when the card fills up.

Happy to report that there was no repeat of the error messages or bad frames reported in my previous tests.

Camera is a 7D

[Licaon_Kter]

This is coming along nicely. 

[dfort]

Just a quick note on panning around the sensor in zoom mode. The cameras that I have been testing for the focus pixel project freeze up when the zoom box is moved during recording no matter if Digital Dolly is enabled or disabled. I'm not able to test MLV Lite with dynamic panning but it does work fine no matter where the zoom box is located when recording is started.

By the way, the cameras also freeze with MLV (regular) and RAW so it isn't an MLV Lite issue. Maybe there's a way to move the zoom box with a lua script?

One last point--the focus pixel map for zoom mode works on all of the 21 raw buffer locations.

[josepvm]

I do not shoot video usually, but I have tested mlv_lite on my 50D, with a Sandisk Extreme Pro 160 MB/s 32GB CF card.

MLV lite allows me to record Full HD 1920x1080 at 23 FPS in crop mode during 1min 30 sec (global draw off). This is not possible with regular MLV, I cannot go beyond 20 FPS for continuous Full HD recording, it fails after 15 or 20 seconds if I try to increase FPS. And at 20 FPS MLV lite is more stable than regular MLV (no yellow camera icon during the first seconds of recording, the icon is always green).

The 4GB file splitting works OK now, with the latest raw_rec module posted here.

The drawback is that with MLV lite I get a magenta cast when extracting DNGs with mlv_dump. I need to correct the black level (sending  "--black-fix=1768" option to mlv_dump) to fix it.

[lanternman]

sorry i got a noob question - other than the early bugs for now, are there other disadvantages to MLV Lite files vs full RAW files?