Magic Lantern Forum

Developing Magic Lantern => Modules Development => Topic started by: dmilligan on February 15, 2016, 03:42:22 AM

Title: MLV Lite
Post by: dmilligan on February 15, 2016, 03:42:22 AM
MLV Lite
The sweet taste of MLV with none of the extra calories™

Recently I've been thinking about ways to do away with the old RAW file format (it has a lot of problems (http://)). I had originally thought of creating a sort of hybrid between RAW and MLV formats, with an MLV header at the beginning and then just a dump of raw data after that like the RAW format, but a1ex helped me realize that's it not hard at all to modify raw_rec to generate completely valid MLV files ("MLV Lite" naming credits also go to a1ex). So, that's what I've done, and it seems to be working. Now it needs just needs some testers.

Download: raw_rec.mo (now available in nightly builds)
PR: https://bitbucket.org/hudson/magic-lantern/pull-requests/685/proposal-completely-replace-the-old-raw

There should be virtually no difference between the way this raw_rec operates and the one in the current nightlies with the sole exception that you will get MLV files out of it. You should see almost identical performance and behavior.

There are some caveats to what you get compared to the full mlv_rec:
1. Metadata is only for what the settings were when recording was started (e.g. you get expo metadata, but if you change exposure, you don't get that new information).
2. No audio
3. No card spanning (recording to both CF and SD card)

This needs to be thoroughly tested so we can convince the main devs to merge it. Here are something things you should test:
1. High FPS
2. File splitting at 4GB limit
3. What happens when card runs out of space?
4. Heavy CPU usage options (GD overlays, crop mode preview, etc.)
5. Metadata is correct?
6. Try various MLV converters to make sure they can all handle the files
7. Write performance comparisons (this raw_rec vs. previous raw_rec vs. mlv_rec)

Make sure to fully describe every situation you tested and the results (whether or positive or negative) and tell which camera you're using, and it'd be good to have tests for both 5D3.113 and 123.
Title: Re: MLV Lite
Post by: dfort on February 15, 2016, 05:30:38 AM
Just a quickie test shows that focus pixel fixing with MLVFS is working and it looks like the camera is able to record more frames at the higher resolutions before hitting the "Frame skipped. Stopping." Of course there should be more testing. Just wondering, is dynamic panning, a.k.a. "digital dolly" supported? It looks like the pan information is saved for every frame.
Title: Re: MLV Lite
Post by: reddeercity on February 15, 2016, 06:08:32 AM
Sound Interesting  , This is a good idea  if nothing changes as in speed then I'm 100% for New Fast MLV Lite !
 I'll test on my 5d2 and compare to the old Raw and report back tomorrow .
 
Title: Re: MLV Lite
Post by: dmilligan on February 15, 2016, 01:19:02 PM
@dfort
It's saved for every frame b/c the spec requires it, but currently it's not updated after recording starts. I suppose it wouldn't be a problem to update it though.
Title: Re: MLV Lite
Post by: Danne on February 15, 2016, 01:40:21 PM
Brilliant. Will test as soon as I can.
Title: Re: MLV Lite
Post by: kgv5 on February 15, 2016, 04:57:00 PM
I made some simple tests and really didnt notice any difference (5d3, 1.1.3) in speed vs MLV rec (I tried for example crop mode with 2,8K res and fps override 1080p 38fps and recording duration in seconds was practically the same). But i guess it needs more tests with different settings.
Title: Re: MLV Lite
Post by: Danne on February 16, 2016, 07:31:53 AM
Gotta love your your work dmilligan. Did some morning tryouts. Gotta get to work. Here are my findings.

5D mark III, ML version 1.1.3

MLV Lite         1792x606, 50fps  2178 frames, global draw off   
MLV                1792x606, 50fps  850 frames, global draw off, sound off

MLV Lite         1920x1080 25fps, with or without global draw (focus peaking) Continuously!
                       Viewing the first 1200 frames I couldn,t find any corrupted frames due to global draw on(focus peaking). This is great stabilty for PAL users.
MLV                1920x1080 25fps around 400 to 600 fps depending on global draw on or off, sound off

Problems with invalid header size. In preview window (mlv play on camera) files previewing works for around 1180 frames but I recorded for whole 5 minutes 1920x1080. Probably the first chunk of MLV works then comes the invalid header size issue.

Post processing
The first MLV chunk convert in post not the others filming longer sequences. Used MLP(mlv_dump), worked splendidly(the first MLV chunk).
Same goes for MLVFS, only first chunk of files pops up, M00 etc doesn,t.

Couldn,t get the files to play in MlRawViewer, too bad Baldand seems to have left the ML development.

Didn,t test against format RAW(no time) but I reckon the numbers are identical or close comparing with MLV Lite

Great work.
Title: Re: MLV Lite
Post by: reddeercity on February 16, 2016, 08:38:51 AM
Did a Quick test with the latest Nightly.2016Feb13.5D2212, 5D2
1856x1004 , 1856x1044  @23.976 and 3x crop mode 2048x930 exacted with mlv.dll with pismo mount on WinPro 7
I did not have time today to compare with raw format.

I did have so problems loading the new mlv lite module , there some log files . Will post them later.
Had problems with the overlays not being disabled Like full MLV when you hit record.
So that Slowed down the frames. The overlay Kill performance on the 5d2
If I kill overlays , it seems to kept the speed but not sure as there no debug to see the data recorded.
Well that not totally true , after messing around a bit I would able to enable the data graph with buffer data rate
but I had to disable the Overlays globally so no meters etc...
Would be nice to have it behave like FULL-MLV.

1856x1004 recorded continuously @ 23.976 74.5MB/s Same as the old raw( did not try any HDMI device at this time )
1856x1044 stop at 800 frame (old raw 1880x1058 @ 23.976 is continuous. Very old build I use from Oct24/13)
I did get a few pink/corrupted frames with 1856x1044 no problems with 1856x1004 @ 23.976p .

3x Crop 2048x930 @ 23.976 is continuous , same as the Old Raw nightly build I use (Oct24/13)
***Note*** I use that build because it faster then all of Raw builds to-date.
When I converted the 3xCrop mode mlv lite files all of the 3xCrop files are Pink , just like the black level is wrong.
I remember when crop mode video was being implemented there was the same issue then
back in fall of 2013 if I'm not mistaken .

I need to do more testing  , from what I have  seem so far I like.  ;)
I will post log files and the pink/corrupted dng's in a day or so.
Tested on a CF Lexar 64GB 1066x card

 
 
Title: Re: MLV Lite
Post by: dmilligan on February 16, 2016, 03:18:07 PM
Quote from: Danne on February 16, 2016, 07:31:53 AM
The first MLV chunk convert in post not the others filming longer sequences. Used MLP(mlv_dump), worked splendidly(the first MLV chunk).
Same goes for MLVFS, only first chunk of files pops up, M00 etc doesn,t.
Yeah, I was worried chunk splitting would have issues. Didn't have time to test it (takes too long to record a sample that hits the 4GB barrier). Can you send the first ~20MB of the split file or post a screenshot of a hexdump of the start of the file?

Quote from: reddeercity on February 16, 2016, 08:38:51 AM
Would be nice to have it behave like FULL-MLV.
Well that's sort of missing the point. If you want something that behaves like the full MLV, then use the full MLV. This should behave exactly like raw_rec except give you MLV files. I don't have any plans to modify the feature set of raw_rec, that's outside the scope of this effort. I just want to switch out the format and make sure everything works and achieves the same level of performance as the old raw_rec. If we can achieve that goal and verify it with good test reports, then we can be done with the old raw format once and for all.
Title: Re: MLV Lite
Post by: Danne on February 16, 2016, 04:56:32 PM
Code: [Select]
mlv_dump -o output.M00 -f 20 input.M00Or renamed to MLV extension gives a segmentation fault 11 but here,s a screen dump. Tell me if you need anything else.
Hex_dump
https://drive.google.com/file/d/0B4tCJMlOYfirbHE5d2RrcUFhSWc/view?usp=sharing

Or did you need the first chunk MLV? Anyway here,s the first file as well, shortened.
https://drive.google.com/file/d/0B4tCJMlOYfiraEMxaXNtekcwRms/view?usp=sharing
Title: Re: MLV Lite
Post by: hjfilmspeed on February 16, 2016, 06:59:18 PM
This is an incredible idea!
Title: Re: MLV Lite
Post by: Ottoga on February 16, 2016, 11:27:03 PM
Quote
3. What happens when card runs out of space?

Just a thought, that could also be applied to mlv_rec.mo.

When enabling the module, why not:
1.     check the available space on the card
2.     calculate how many minutes of recording time is available based on the resolution and crop mode set at the time of pressing the
        start recording button. (Max recording)
3.     reduce the calculated available time by say 1 minute (to maintain some free space overhead) - (Allowed Recording)
4.     display this on the screen with a continue y/n? option.
5.     Automatically stop recording when the allowed recording time has been reached.

I think that this would allow the MLV file/last segment to be closed correctly thereby eliminating the number of "Card full" issues raised with MLV recording. Step 4 would give the operator a chance to clear space on the card or swap it out for a larger capacity one if the allowed capacity was insufficient for their needs and/or rethink their filming strategy to work around the space constraint.
Title: Re: MLV Lite
Post by: menoc on February 17, 2016, 12:34:09 AM
Simply Put: "MLV_REC without the overhead . . ."
Title: Re: MLV Lite
Post by: dmilligan on February 17, 2016, 12:50:51 AM
@Ottoga,

Again, adding new features like this are beyond the scope of this effort.

I just want to know what happens when the card runs out of space. Are you still able to convert the file?
Title: Re: MLV Lite
Post by: dmilligan on February 17, 2016, 03:40:50 AM
Quote from: Danne on February 16, 2016, 07:31:53 AM
The first MLV chunk convert in post not the others filming longer sequences. Used MLP(mlv_dump), worked splendidly(the first MLV chunk).
Same goes for MLVFS, only first chunk of files pops up, M00 etc doesn,t.
I think I fixed the issue. Binary updated, please retry.
https://bitbucket.org/dmilligan/magic-lantern/downloads/raw_rec.mo
Title: Re: MLV Lite
Post by: reddeercity on February 17, 2016, 06:06:41 AM
Ok I hear you on the scope of this ,
More information  , Spanning works only up to 1 file  2 or more will crash any app I try.
Tested on MLVFS (Mac) (I don't have the latest updated version)
Raw2Cdng ver.1.65 (Win) , note the 3xCrop file looked find in the preview window (not Pink)
MLVProducer (ver.2224-Intel)(Win) also crashed on 2 or more spanning files , but there again the 3X Crop file looked ok (not Pink)
Here the crash log from MLVProducer  mlvproducer log file (https://www.dropbox.com/s/3enfczjlk1zvjkz/MLVProducer%20Crash%20Log.txt?dl=0)

Seems the mlv.dll with Pismo was the only app producing pink(wrong black level I think) frame from 3xCrop mode.
Maybe the mlv.dll needs up dating , not sure.
 
when the Cf card was full , I didn't know and try to record just came back with a error message "file corrupted or something to that effect".
Made 3 files , that crashed all PC apps but MLVFS did not crash ,  open up the web page but display nothing , just files names.
Here the link to those 3 file ,(very Small)  MLV_Lite_Card_Full.zip (https://www.dropbox.com/s/1t7tyx3ln4pfz9d/MLV_Lite_Card_Full.zip?dl=0)
After that rebooted the cam with that same card , camera displayed a "Full Card" message.

When I first tried to load that module  , I had problems here is the Log files it generated ASSERT00-18.zip (https://www.dropbox.com/s/e41xjuojydoygo6/ASSERT00-18.zip?dl=0) . It keep generating files until I reboot the Cam. then it was ok

Lastly here is the pink/corrupted dng's frames in a zip file only 30Mb   dng's frames.zip  (https://www.dropbox.com/s/ka6zt6pq7hyskkr/Pink%20Frames.zip?dl=0)

Edit: Notice you posted a updated version or the raw_rec.mo will try it out tomorrow & report back.




Title: Re: MLV Lite
Post by: Danne on February 17, 2016, 07:29:11 AM
Tried the latest raw_rec here
http://www.magiclantern.fm/forum/index.php?topic=16650.msg162413#msg162413

Will post dumps later

Longer sequences works with MLVFS. Tested 5 minute clip, about 7000 frames, 28gb file
Longer sequences won,t work with mlv_dump. Only the first chunk will create dng files.
Mlv_dump will convert to dng files if it has only one spanned file recorded, M00, then it processes both the files but only the first if the recording has more than one extra chunk, then it will only process the first chunk called MLV.
More testing later.
Work...


Here are some files.
I shortened the first MLV and the M00 is an entry hex_dump.
MLV_lite. Originally three chunks, only the first will process in mlv_dump
https://drive.google.com/file/d/0B4tCJMlOYfirbml5WXdFQVFXcEE/view?usp=sharing

Regular mlv file, three chunks. Processing works with mlv_dump (comparing maybe)
https://drive.google.com/file/d/0B4tCJMlOYfirMU5LN21BQXV1SU0/view?usp=sharing

If you need something else let me know.
Title: Re: MLV Lite
Post by: DeafEyeJedi on February 17, 2016, 08:01:59 AM
Loving this Project and it's progress so far ... sorry I have been out and about with work and life as we all know, right?!

Anyway here's what I was able to accomplish with reading from MLVFS with the new raw_rec.mo files that I downloaded and placed into the Binaries folder under ML.

I then test shot a bunch of slo-mo's in varieties FPS.

(https://farm2.staticflickr.com/1639/24454733363_d5b5b009f5.jpg) (https://flic.kr/p/DfYUeR)

Noticed the two empty lines (MLV #2148 & #2256) which were spanning files with .M00, .M01, etc in their respective destination -- not sure what could be the culprit here?

However, I have tried running some of the new raw_re.mo MLV's that show up 'Black Screen of Death' upon viewing footage in MLRawViewer ... Not all but some and will need to investigate further more to confirm this more in depth.

(https://farm2.staticflickr.com/1444/24455097983_7b7f21ce3d_n.jpg) (https://flic.kr/p/Dg1LCp)

Until I tried DR12 while running MLVFS and the first file recorded shows up fine (screenshot below) as oppose to MLRV (screenshot above). Maybe this has to do with mlv_dump? Or the header?

(https://farm2.staticflickr.com/1620/24963758172_0c28f4a12a_n.jpg) (https://flic.kr/p/E2XMzE)

I am currently running some of those files with @Danne's recent updated version of MLP and will report back once I find the results. I am also in the middle of updating @AWPStar's MLVProucer on my Mac under Wine and will report that back as well.

Gotta get some sleep and off to work early in AM. Thanks again David for your excellent innovations that just seems to never end!  :D
Title: Re: MLV Lite
Post by: dmilligan on February 18, 2016, 01:42:46 PM
Quote from: reddeercity on February 17, 2016, 06:06:41 AM
Seems the mlv.dll with Pismo was the only app producing pink(wrong black level I think) frame from 3xCrop mode.
Maybe the mlv.dll needs up dating , not sure.
Pismo is obsolete: http://www.magiclantern.fm/forum/index.php?topic=13152.msg161902#msg161902

Quote from: reddeercity on February 17, 2016, 06:06:41 AM
When I first tried to load that module  , I had problems here is the Log files it generated ASSERT00-18.zip (https://www.dropbox.com/s/e41xjuojydoygo6/ASSERT00-18.zip?dl=0) . It keep generating files until I reboot the Cam. then it was ok
That error is actually coming from mlv_rec. You probably had both loaded, which is causing some sort of conflict.

@Danne, @DeafEyeJedi
Recording multiple chunks is working just fine here, so I'm not sure what's going on, and everything in the sections of the files you sent me looks correct. The only thing that's "wrong" is the fileCount field (it's always 0, b/c we don't go back and update it after we've created new chunks), but it's allowed to be wrong:
Quote
- fileCount field in the header may get set to the number of total chunks in this recording
And files like this process just fine for me in mlv_dump and MLVFS.

What's the output of mlv_dump -v for the files with multiple chunks?
If you rename each .MXX chunk to .MLV will they process by themselves?
(make sure to delete any .IDX files before trying anything new)

@DeafEyeJedi,
Anything in mlvfs log file? ~/.mlvfs.log
Title: Re: MLV Lite
Post by: Danne on February 18, 2016, 02:10:45 PM
Here is terminal output from a working set of three spanned files (regular MLV)
Code: [Select]
MLV Dumper v1.0
-----------------

Mode of operation:
   - Input MLV file: '/Users/Daniel/Desktop/mlv/regular mlv/M17-0810.MLV'
   - Convert to DNG frames
   - Output into 'hej'
File /Users/Daniel/Desktop/mlv/regular mlv/M17-0810.MLV opened
File /Users/Daniel/Desktop/mlv/regular mlv/M17-0810.M00 opened
File /Users/Daniel/Desktop/mlv/regular mlv/M17-0810.M01 opened
File /Users/Daniel/Desktop/mlv/regular mlv/M17-0810.M02 not existing.
Processing...

Vertical stripes correction:
  1.000  1.000  0.995  1.021  0.997  0.997  0.995  1.004
Reached end of chunk 1/3 after 2764 blocks
Reached end of chunk 2/3 after 2687 blocks
Reached end of chunk 3/3 after 1 blocks
Processed 2683 video frames
Done


Here,s the output from three spanned files recorded with mlv_lite
Code: [Select]
MLV Dumper v1.0
-----------------

Mode of operation:
   - Input MLV file: '/Users/Daniel/Desktop/mlv/mlv_lite not working/M17-0807.MLV'
   - Convert to DNG frames
   - Output into 'hej'
File /Users/Daniel/Desktop/mlv/mlv_lite not working/M17-0807.MLV opened
File /Users/Daniel/Desktop/mlv/mlv_lite not working/M17-0807.M00 opened
File /Users/Daniel/Desktop/mlv/mlv_lite not working/M17-0807.M01 opened
File /Users/Daniel/Desktop/mlv/mlv_lite not working/M17-0807.M02 not existing.
Processing...

Vertical stripes correction:
  1.000  1.000  0.995  1.016  0.999  0.997  0.998  1.003
[ERROR] VIDF: File ends in the middle of a block
Processed 1182 video frames
Done
Quote
If you rename each .MXX chunk to .MLV will they process by themselves?
Yes, working.

Verbose output
First lines
Code: [Select]
MLV Dumper v1.0
-----------------

Mode of operation:
   - Input MLV file: '/Users/Daniel/Desktop/mlv/mlv_lite not working/M17-0807.MLV'
   - Verbose messages
   - Convert to DNG frames
   - Output into 'hej'
File /Users/Daniel/Desktop/mlv/mlv_lite not working/M17-0807.MLV opened
File /Users/Daniel/Desktop/mlv/mlv_lite not working/M17-0807.M00 opened
File /Users/Daniel/Desktop/mlv/mlv_lite not working/M17-0807.M01 opened
File /Users/Daniel/Desktop/mlv/mlv_lite not working/M17-0807.M02 not existing.
Processing...
File Header (MLVI)
    Size        : 0x00000034
    Ver         : v2.0
    GUID        : 7343463891422747826
    FPS         : 25.000000
    File        : 0 / 0
    Frames Video: 0
    Frames Audio: 0
Block: RAWI
  Offset: 0x00000034
    Size: 180
    Time: 0.768000 ms
    Res:  1920x1080
    raw_info:
      api_version      0x00000001

Verbose output
Last lines
Code: [Select]
Block: VIDF
  Offset: 0xfff7221c
    Size: 3633152
    Time: 48853.163000 ms
   Frame: #1182
    Crop: 152x132
     Pan: 146x133
   Space: 4064
[ERROR] VIDF: File ends in the middle of a block
Processed 1182 video frames
Done

Code: [Select]
[ERROR] VIDF: File ends in the middle of a blockSeems to be what is happening here.
Title: Re: MLV Lite
Post by: Ottoga on February 18, 2016, 02:57:41 PM
MLVLite Tests
--------------------
Camera:   7D
ML Build:   magiclantern-Nightly.2016Feb13.7D203
raw_rec.mo  (2nd lite build)

Cards used: Sandisk Extreme III 8GB 30MB/s
                  KB 128gb 1000x

PC:    ASUS Intel i5 quad core laptop


Tested with:
    -    Default raw resolution with continuous recording to generate spanned file mlv, m00, m01... etc. The longest went to m14.
    -    Some alternate resolutions
    -    5x and 10x crops
    -    fps override
    -    ettr "always on" for all tests
    -    global draw off for all tests
    -    kept recording and creating files unill both cards ran out of space

General observations

1)    When in 10x crop mode recording failed to start when pressing the record start button.
       There are 14 MLV files (M18.1841-1855) created with a 1kb size and in the same time window there is a file called backup.raw 512kb that was created. I believe
       that these files are all related the 10x recording failure.
       Whilst pressing the start record button, I ultimately managed to observe the following message that flickered onto the screen after each button press:
                  "Raw detected error".

      Link to backup.raw file: http://1drv.ms/1R9MEeo

2)    When the card ran out of space the following occured:
      :    The message "Movie recording stoped automatically, Data corruption @slot nn, frame nnnnn (where nn  is a numeric number)
           This message appeared a few times before ultimately staying on screen. The frame number changed for each occurance of
           the message, can't remember whether the slot numumber did.
      :    The CF access LED remained lit.
      :    I pressed the stop recording button, waited a bit but nothing changed so I powered the camera off (the LED stayed lit).
    At this stage,
      :    for the 1st (8gb) card, I removed and reinserted both the battery and the CF card (thnking that the camera had frozen).
           -  Powered the camera backup and receive a message that the camera had not been shut down correctly. Otherwise the camera
              booted normally, including ML.
      :    for the second (128gb) card I just powered the camera backup again.
              I received a "CF Card is Full" message, however the camera booted normally, including ML.
      :    I was able to copy all files off the CF cards to my local harddrive.

    From this, my inital observation would be that for the 7D at least, running out of space whilst recording will not brick the camera
    or corrupt the CF card.

3)  With the exception of the 1kb size MLV files all of the others mounted without error in MLVFS.

     localhost view:   http://1drv.ms/1Lv3NLp

     CMD Lin view:   http://1drv.ms/1Lv3TlY

4)  Excluding the 1kb size MLV files all of the others successfully loaded into and played in MLVProducer (version: mlvp.alpha.build2224b.INTEL)

5)  Via the Dokan v1rc mounts I can successfully import the DNG's into my Photo and video editing applications. A quick visual scan of the individual frames didn't spot
     any bad or pink frames.


Let me know if there are any other specific tests that you would like me to do.
Title: Re: MLV Lite
Post by: Danne on February 18, 2016, 03:10:24 PM
@Ottoga.
Will your files convert properly using mlv_dump?
Title: Re: MLV Lite
Post by: Ottoga on February 18, 2016, 03:14:32 PM
@Danne

I haven't tried this. I'll give it a go in the morning and report back.
Title: Re: MLV Lite
Post by: Ottoga on February 19, 2016, 05:10:39 AM
@Danne  @Dmilligan

Quote
5)  Via the Dokan v1rc mounts I can successfully import the DNG's into my Photo and video editing applications. A quick visual scan of the individual frames didn't spot
     any bad or pink frames.

Correction to the above.  Upon closer inspection I found that for the recordings that were in progress at the time that the CF card ran out of space: the last frame of each was corrupt.


I processed all of the multi-chunk mlvs and a couple of single chunk ones through mlv_dump. The tests resulted in a mixed bag of outcomes.

At launch, mlv_dump listed all of the available file chunks to be processed but listed the next logical one in the chain as "Not Existing" Ref: to the linked screen shots for examples. I suspect that this is standard mlv_dump behaviour.

A number of files failed to process all of the available chunks with a common error message:  ERROR VIDF: File ends in the middle of a block

The following links are the mlv-dump screenshots for the files related to the recordings that were in progress at the time the CF cards ran out of space. Both of these files suffered the above error however, it was on the last (and corrupt) frame that it occurred.

M18-1704.mlv and last file on the 8gb card:      http://1drv.ms/1oO2276   1 Chunk, 1399 of 1400 frames processed
M18-1856.mlv and last file on the 128gb card:  http://1drv.ms/1Qpej7U    9 chunks, 13508 of 13509 frames processed

The following links are for files where mlv_dump failed to process all of the available frames.

M18-1658.mlv:  http://1drv.ms/1oO2rXh     2 chunks, only processed the first 3276 of 4050 frames before erroring out
M18-1805.mlv:  http://1drv.ms/1oO2Rgh     3 chunks, only processed the first 1458 of 44214 frames before erroring out

The following links are for files processed through mlv_dump that processed error free.

M18-1655.mlv: http://1drv.ms/1Ktv59V         1 chunk,    1031 frames processed
M18-1808.mlv: http://1drv.ms/1oO37fd       16 chunks, 23150 frames processed
M18-1826.mlv: http://1drv.ms/1XATnR8        1 chunk,      601 frames processed (fps 1 frame per second)

I was running multiple instances of mlv_dump. To verify the results I re-ran a number of the mlvs with a single instance of mlv_dump running and got the same results.


My thoughts are that mlv_dump is not able to handle the mlv_lite files that had skipped frames or where the mlv_lite file closes abruptly due to things like non default resolutions and high resolution crop mode.

Cheers... Otto
Title: Re: MLV Lite
Post by: dmilligan on February 19, 2016, 01:55:25 PM
The issue here is the 4GB file size limit on Fat32. The file IO routines in Canon firmware respond to this limit in different ways for different cameras (they vary slightly in other ways too). Some cameras will fail immediately if there's not enough room before the 4GB for the current requested write, while others will fill up to the end of 4GB exactly, then fail. We could just always stop before getting to the limit, but we don't necessarily know in advance if there is a 4GB limit or not (ExFAT does not have a 4GB limit). The only way to know if there is a 4GB limit is to actually hit it (well, I suppose there might be other ways to find out).

The old raw format simply allowed frames to span across files, so one chunk might end in the middle of a frame and then the remaining part of the frame would start the next file. MLV format does not allow this.

If mlv lite hits the 4GB limit, it will start the next chunk with the current frame that failed to write, so there's actually nothing wrong with the next chunk file (that's why if you rename it to MLV it will process correctly). The problem is what happens at the end of the previous chunk. If the camera doesn't write any data when there's not enough room left under the 4GB limit, then there's no problem, but if the camera writes some of that data, then the file will end in the middle of a frame. So mlv lite needs to go back and clean it up.

Here's a visual example:
                                                     4GB Limit->|
[MLVI][VIDF1-01010101][VIDF2-01010101][VIDF3-01010101][VIDF4-01010101]

Sometimes this happens:
[MLVI][VIDF1-01010101][VIDF2-01010101][VIDF3-01010101]
Yay! everything is fine

but sometimes this happens:
[MLVI][VIDF1-01010101][VIDF2-01010101][VIDF3-01010101][VIDF4-0101

What it tries to do if this happens is replace the last VIDF with a NULL so it will be ignored:
[MLVI][VIDF1-01010101][VIDF2-01010101][VIDF3-01010101][NULL-0101]

It appears that the cleanup does not work reliably on all cameras. If it doesn't happen right, then mlv_dump will give you an error that the file ends in the middle of a block. There's actually no reason mlv_dump couldn't just keep processing if this situation happens, and simply emit a warning, rather than an error. The frame that got chopped off will be in the next chunk in it's entirety.

The same sort of thing happens when the card runs out of space, but in this situation we don't even bother to try and clean it up, there's nothing going to come after this frame anyway. If the last frame is corrupted, well, that's to be expected. As long as all the rest of the file processes correctly, I'm not worried about it.
Title: Re: MLV Lite
Post by: Danne on February 19, 2016, 02:17:21 PM
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?
Title: Re: MLV Lite
Post by: Ottoga on February 19, 2016, 03:18:42 PM
@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.
Title: Re: MLV Lite
Post by: dmilligan on February 19, 2016, 04:38:26 PM
Quote from: Danne on February 19, 2016, 02:17:21 PM
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.

Quote from: Danne on February 19, 2016, 02:17:21 PM
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.

Title: Re: MLV Lite
Post by: dfort on February 20, 2016, 02:47:59 AM
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
(https://farm2.staticflickr.com/1662/24841819030_5b543eb053_z.jpg)

MLV
(https://farm2.staticflickr.com/1644/24510621863_c2cd85af2d_z.jpg)

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 Lite63 frames
MLV66 frames
Raw71 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]
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]
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]
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]
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.
Title: Re: MLV Lite
Post by: dmilligan on February 20, 2016, 09:49:59 PM
I think I fixed the spanning issue. New version uploaded:
https://bitbucket.org/dmilligan/magic-lantern/downloads/raw_rec.mo
Title: Re: MLV Lite
Post by: Danne on February 20, 2016, 10:34:19 PM
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.
Title: Re: MLV Lite
Post by: Ottoga on February 20, 2016, 11:58:07 PM
@dmilligan

A promising result from Dane.  Will rerun tests on my 7d when I get back home (2 days).
Title: Re: MLV Lite
Post by: Danne on February 21, 2016, 03:44:37 PM
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.

Title: Re: MLV Lite
Post by: dfort on February 21, 2016, 05:16:12 PM
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:
Quote
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.
Title: Re: MLV Lite
Post by: Danne on February 21, 2016, 05:50:51 PM
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  :P.
Title: Re: MLV Lite
Post by: SteveScout on February 21, 2016, 06:11:27 PM
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!!
Title: Re: MLV Lite
Post by: AWPStar on February 22, 2016, 07:06:39 AM
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
Title: Re: MLV Lite
Post by: dmilligan on February 22, 2016, 01:20:36 PM
Quote from: dfort on February 21, 2016, 05:16:12 PM
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.
Title: Re: MLV Lite
Post by: Canon eos m on February 23, 2016, 10:03:30 AM
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.
Title: Re: MLV Lite
Post by: CITY-U1001 on February 23, 2016, 11:12:01 AM
make 2000x1080 for 50D, its work in last Tragic Lantern  :-\
Title: Re: MLV Lite
Post by: Canon eos m on February 23, 2016, 12:42:55 PM
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.
Title: Re: MLV Lite
Post by: dfort on February 23, 2016, 06:13:12 PM
Quote from: CITY-U1001 on February 23, 2016, 11:12:01 AM
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.
Title: Re: MLV Lite
Post by: dmilligan on February 23, 2016, 07:55:32 PM
Quote from: dfort on February 23, 2016, 06:13:12 PM
It needs to be a multiple of 16
32 ;)
Title: Re: MLV Lite
Post by: dfort on February 23, 2016, 09:04:47 PM
2016 - 1984 = Doh!

There you go exposing my math skills again. Updated my post.
Title: Re: MLV Lite
Post by: reddeercity on February 24, 2016, 04:54:29 AM
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) :P 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  :o

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 .

 



Title: Re: MLV Lite
Post by: Ottoga on February 25, 2016, 01:52:55 PM
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
Title: Re: MLV Lite
Post by: Licaon_Kter on February 26, 2016, 10:27:09 AM
This is coming along nicely.  :o
Title: Re: MLV Lite
Post by: dfort on February 26, 2016, 04:46:12 PM
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.
Title: Re: MLV Lite
Post by: josepvm on February 27, 2016, 12:08:42 PM
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.
Title: Re: MLV Lite
Post by: lanternman on February 27, 2016, 10:48:51 PM
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?
Title: Re: MLV Lite
Post by: Walter Schulz on February 27, 2016, 10:52:01 PM
Covered in first post.
Title: Re: MLV Lite
Post by: dfort on February 28, 2016, 06:16:18 AM
Quote from: lanternman on February 27, 2016, 10:48:51 PM
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?

What do you mean by "full" RAW files?

Differences from "full" MLV:
Quote
1. Metadata is only for what the settings were when recording was started (e.g. you get expo metadata, but if you change exposure, you don't get that new information).
2. No audio
3. No card spanning (recording to both CF and SD card)

Differences from RAW v1.0 is that some of the testers are finding that the older format still has a slight edge in performance when you're really pushing the envelope at the expense of almost no metadata to work with in post production.

In practice the difference are more significant. MLV is a big improvement over v1.0 RAW in terms of the amount of metadata saved in the files that can be useful in post production and even more significant, being able to record synced audio. However, there are issues with "pink frames" and other problems that have come up on occasion so some users have reverted to the old RAW format. MLV Lite is designed to ween users off of the old RAW format by giving "The sweet taste of MLV with none of the extra calories" -- makes sense?

@dmilligan -- hope you approve of my editorializing.

@WalterSchulz -- Your response was much more concise but I wanted to add my own thoughts about MLV Lite. Seems like my tests have been favoring the old format.
Title: Re: MLV Lite
Post by: Licaon_Kter on February 29, 2016, 01:03:35 AM
EOS M, auto UI, warmup 64Mb

mlv_rec = 1728x... records >1000frames
mlv_lite = frameskip after 2 secs

mlv_rec = 1280x... records continously
mlv_lite = frameskip after 30 secs
Title: Re: MLV Lite
Post by: Danne on March 01, 2016, 11:04:43 AM
There has been some posts about corrupted frames with mlv lite in MLP thread which when looking further into it was a user issue because of a mix up filming with regular MLV not mlv lite. No corrupted frames with MLV lite yet that is. Good news.
Here,s the faulty description.
http://www.magiclantern.fm/forum/index.php?topic=13512.msg163300#msg163300
Title: Re: MLV Lite
Post by: Danne on March 01, 2016, 04:56:37 PM
Played around with a 7D at work. Downloaded magiclantern-Nightly.2016Feb29.7D203.zip and installed.
Ran filming in 60 mv720 mode fps around 1500 x 540 in size(not exact numbers). Actually produced a lot of corrupt frames when using global draw and focus peaking. Global draw off yields no corrupted frames, everything works ok. Surprisingly I had the same corrupt image problems with old format RAW when doing the same tests so this test doesn,t say anything more than that they are both corrupted. Here is a shortened mlv_lite file if of any use.
https://drive.google.com/file/d/0B4tCJMlOYfirZTR5SE1qUW9BZ28/view?usp=sharing

Conclusion. Both RAW and mlv lite can produce corrupt frames.

Gonna try some regular fps 24-25 fps footage as well. Update coming up.

*Regular HD(1728x972) 25fps with global draw on, focus peaking works fine with no corrupted frames with mlv lite.
Title: Re: MLV Lite
Post by: Steve_FR on March 08, 2016, 02:06:09 AM
Eos-M Nightly 2/29/2016

5x Zoom Raw, Frame size: 1728x736 aspect 2:35 @ 23.97 fps (fps override enabled)
MLV 2.0            - 175 to 176 frames (7 seconds)
MLV Lite            - 150 to 160 frames (listed as "zero frames")
ML Raw 1.0    - 223 to 229 frames (9 seconds)
Title: Re: MLV Lite
Post by: reddeercity on March 08, 2016, 04:24:05 AM
Quote from: Danne on March 01, 2016, 04:56:37 PM
Actually produced a lot of corrupt frames when using global draw and focus peaking. Global draw off yields no corrupted frames, everything works ok.
Yes that been noted before with the 7D & 5D2 back a few years ago now.
I used to get corrupt frames when I use GD enabled (5D2)  , it's just to much for system to handle  at least at max. resolution .
I guess that why on the 5d2 the GD automatically is disable when raw video starts in MLV2.0 only thou.
Title: Re: MLV Lite
Post by: Danne on March 08, 2016, 07:30:33 AM
That is important information. Harder to test the problem.
Title: Re: MLV Lite
Post by: dfort on March 12, 2016, 12:50:30 AM
@dmilligan

Just a quick question. Would it be possible to implement something like LZ4 (http://cyan4973.github.io/lz4/) or FastLZ (http://fastlz.org/) before the data hits the memory card? It seems that the bottle neck is in the writing speed, especially for cameras using SD cards. Only a tiny bit of compression would be needed to exceed the performance of RAW 1.0.

I have a feeling you're going to say that the ARM processor isn't powerful enough but thought I'd ask anyway.
Title: Re: MLV Lite
Post by: dmilligan on March 12, 2016, 12:59:48 AM
Even memcpy (straight memory copy using the cpu) is too slow... The only way raw video works is with specialized external memory controller that can copy huge chunks of memory around very quickly with no CPU overhead.
Title: Re: MLV Lite
Post by: johannsebastianbach on March 13, 2016, 07:33:46 PM
Hey fellas :) Is there any good way to preview MLV-Lite in realtime, like it works for normal MLV's with MlRawViewer? I'm not very up to date - neither is my 2008'Macbook :D
Title: Re: MLV Lite
Post by: dmilligan on March 13, 2016, 10:32:43 PM
Talking about on a computer? Does MlRawViewer not work with these files?
Title: Re: MLV Lite
Post by: johannsebastianbach on March 13, 2016, 11:14:46 PM
MLV Preview module is working fine on the camera. My Mac is too slow to preview in after effects (not to mention resolve) but was always previewing in realtime in MlRawViewer. Unfortunately MlRawViewer shows only a black screen if I try a MLV Lite.

Good news is: I just had a weekend shooting 120GB of MLV Lite and not a single pink frame with 1920x490 @ 50fps Global Draw ON with cropmarks and freakin' FOCUS PEAK  :o I'm so astonished, it was nice to be able to focus pull easily in slow motion which was impossible with normal MLV without getting pink frames.

My workflow normally was: previewing the MLV's with MlRawViewer and pick the ones I want to open with MLVFS for further processing (MLFVS is the Reason I like MLV instead of RAW, for space saving workflow without having to export to cDNG first). I'm using 5DIII OSX 10.11.3 MlRawViewer 1.4.3.
Title: Re: MLV Lite
Post by: DeafEyeJedi on March 15, 2016, 08:52:06 PM
I second that as well ... MLV Lite files do not work with MLRV but with AE or DR it all seems fine like normal. I suspect it has to do with the heading of the file. Not that big of a deal but it would be nice if there was a fix for this small bug.
Title: Re: MLV Lite
Post by: johannsebastianbach on March 17, 2016, 02:26:41 PM
Little problem over here, one of the 174 mlv´s lite  I´ve shot is previewing fine in OSX Finder, but when I open it in CameraRAW to debay its black. Tried MLVFS and MLP. Any fix for that? :) Thank ya´ll in advance.

EDIT: 5dIII, OSX11, ML1.1.3, 50fps, MLV Lite, 1920x490

(http://picload.org/image/wpciroo/screenshot2016-03-17at14.11.47.png)


(http://picload.org/image/wpcirod/screenshot2016-03-17at14.11.26.png)
Title: Re: MLV Lite
Post by: Walter Schulz on March 17, 2016, 02:40:25 PM
70D?
Title: Re: MLV Lite
Post by: johannsebastianbach on March 17, 2016, 02:44:48 PM
Quote from: Walter Schulz on March 17, 2016, 02:40:25 PM
70D?

Sorry, forgot: 5dIII, OSX11, ML1.1.3, 50fps, MLV Lite, 1920x490
Title: Re: MLV Lite
Post by: Danne on March 17, 2016, 03:03:01 PM
Corrupt frame? Do you have the actual mlv file or a sample dng?
Title: Re: MLV Lite
Post by: johannsebastianbach on March 17, 2016, 03:16:48 PM
Quote from: Danne on March 17, 2016, 03:03:01 PM
Corrupt frame? Do you have the actual mlv file or a sample dng?

It is one mlv of 174 recorded (didn't change any settings in the recording series) and all of the cDNG's in this perticular mlv. Finder preview works fine.

Here to download, thanks (MLFVS same as MLP): https://dl.dropboxusercontent.com/u/24873307/M13-1536_000470.dng
Title: Re: MLV Lite
Post by: Danne on March 17, 2016, 03:30:12 PM
Thanks. Seems corrupted. Preview seems fine though. Only one bad fram out of 174 mlv files shot in 50fps? That seems to me like mlv_lite is a trustworthy format.
Title: Re: MLV Lite
Post by: johannsebastianbach on March 17, 2016, 03:41:01 PM
Quote from: Danne on March 17, 2016, 03:30:12 PM
Thanks. Seems corrupted. Preview seems fine though. Only one bad fram out of 174 mlv files shot in 50fps? That seems to me like mlv_lite is a trustworthy format.

It's all frames in the whole MLV. But one MLV out of 174. So not a corrupted frame - since the preview works fine I guess there is a way somehow to fix it.

Otherwise though mlv lite is extremly stable. I didn't have one corrupt frame (only this MLV) even with using focus peak in 50fps! The one and only reason left for me not to use it is the realtime previewing option. It doesn't work in MlRawViewer and now I had to export proxies which tooke about 50 hours to render just to preview and be able to choose the actual footage i am going to use for the cut - you cannot decently preview on the set and know only after days if you fucked something up maybe :)
Title: Re: MLV Lite
Post by: Danne on March 17, 2016, 03:54:30 PM
50 hours. A lot of footage. Did you run it through MLP?
By the way. You can run MlRawViewer by selecting a dng file inside the dng folder. That means you can run MlRawViewer straight through MLVFS with Mlv-lite footage without the need to spend 50 hours on proxies  :P.
Title: Re: MLV Lite
Post by: johannsebastianbach on March 18, 2016, 12:59:29 PM
That is an truly awesome advice! Didn't know MlRawViewer can open up a cDNG sequence. Thank you Danne!  :)

It's not a lot of footage (120gb of mlv), but just a slower macbook - 2 GHz Intel Core 2 Duo, 8 GB 1067 MHz DDR3, NVIDIA GeForce 9400M 256 MB. It is still usable for all work though, even cutting with proxies (CameraRaw workflow).

EDIT: About the corrupt MLV. MlRawViewer shows it black too, it's really weird, that OSX Preview shows it correctly.
Title: Re: MLV Lite
Post by: Danne on March 18, 2016, 02:20:27 PM
Not really. The preview pic is only a preview. The actual raw data could therefore be corrupt while previewe shows correctly.
Title: Re: MLV Lite
Post by: dmilligan on March 18, 2016, 02:53:42 PM
There is no separate preview data in an MLV file. If a preview somehow looks correct then the original raw data is intact, b/c that preview had to have come from the real original raw image data in the MLV file. I highly doubt there is image data corruption, something else is wrong, probably incorrect black level => Finder uses a hard coded back level and ignores the value in the file, so if the value in the file is wrong, preview will still show correctly.

Also, most cDNG converters (MLVFS included) don't embed a separate preview image in the DNGs (b/c Adobe Premiere and others don't like it), so the Finder is likely showing the full image data.
Title: Re: MLV Lite
Post by: dmilligan on March 19, 2016, 03:06:10 AM
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.
Title: Re: MLV Lite
Post by: a1ex on April 13, 2016, 05:00:56 PM
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
Title: Re: MLV Lite
Post by: platu on April 18, 2016, 11:42:19 PM
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.
Title: Re: MLV Lite
Post by: DeafEyeJedi on April 20, 2016, 09:59:24 AM
and what's wrong with MLVFS + DR12 for quick previews @platu?
Title: Re: MLV Lite
Post by: a1ex on April 20, 2016, 10:27:36 AM
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.
Title: Re: MLV Lite
Post by: Licaon_Kter on April 20, 2016, 12:17:10 PM
Quote from: a1ex on April 20, 2016, 10:27:36 AM
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. :)
Title: Re: MLV Lite
Post by: dmilligan on April 20, 2016, 01:46:29 PM
Workaround: use MLVFS and MLRawViewer together (MLRawViewer is capable of playing back DNG files).
Title: Re: MLV Lite
Post by: a1ex on April 20, 2016, 03:26:16 PM
During my experiments (http://www.magiclantern.fm/forum/index.php?topic=17091), 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).
Title: Re: MLV Lite
Post by: kidfob on April 20, 2016, 05:43:29 PM
@DeafEye, I sent you a PM. Did you get it? Thanks
Title: Re: MLV Lite
Post by: DeafEyeJedi on April 20, 2016, 07:06:07 PM
Quote from: a1ex on April 20, 2016, 10:27:36 AM
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!  :P

Quote from: dmilligan on April 20, 2016, 01:46:29 PM
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!

Quote from: kidfob on April 20, 2016, 05:43:29 PM
@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!
Title: Re: MLV Lite
Post by: platu on April 21, 2016, 08:13:36 AM
Quote from: DeafEyeJedi on April 20, 2016, 09:59:24 AM
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.
Title: Re: MLV Lite
Post by: a1ex on April 21, 2016, 08:27:08 AM
+1. I didn't see it as complaining, and we should not discourage this kind of reports.
Title: Re: MLV Lite
Post by: DeafEyeJedi on April 21, 2016, 08:32:06 AM
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.
Title: Re: MLV Lite
Post by: platu on April 21, 2016, 08:56:50 AM
Quote from: dmilligan on April 20, 2016, 01:46:29 PM
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.
Title: Re: MLV Lite
Post by: platu on April 21, 2016, 09:41:11 AM
@DeafEyeJedi, No worries... I'm not easily discouraged anyway ;)
Title: Re: MLV Lite
Post by: johannsebastianbach on April 21, 2016, 06:19:43 PM
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.
Title: Re: MLV Lite
Post by: Danne on April 21, 2016, 07:12:59 PM
Could it be as trivial as mlv_lite doesn,t report amount of frames? 
Title: Re: MLV Lite
Post by: Danne on May 03, 2016, 11:05:48 AM
Bouncyball just confirmed this regarding MlvRawViewer.
Quote
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


Title: Re: MLV Lite
Post by: DeafEyeJedi on May 06, 2016, 05:10:10 AM
Nice work @Danne ... at least it seems we are heading towards on the right path.

Thanks for your kind contributions @bouncyball!
Title: Re: MLV Lite
Post by: keepersdungeon on May 26, 2016, 09:20:37 AM
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?
Title: Re: MLV Lite
Post by: THEMESSIAH on August 27, 2016, 08:24:53 PM
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
Title: Re: MLV Lite
Post by: Danne on January 20, 2017, 01:47:51 PM
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.
Title: Re: MLV Lite
Post by: a1ex on January 20, 2017, 02:44:25 PM
Looking into it.

Are you sure it's a performance issue?
Title: Re: MLV Lite
Post by: Danne on January 20, 2017, 02:55:36 PM
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.
Title: Re: MLV Lite
Post by: a1ex on January 20, 2017, 05:49:51 PM
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.
Title: Re: MLV Lite
Post by: Danne on January 20, 2017, 06:31:22 PM
Yes, padding, remember dmilligan,s solution from before.
Anyway. Tested push and working.
Thanks.
Title: Re: MLV Lite
Post by: a1ex on February 12, 2017, 09:30:05 PM
This module is now available in the nightly builds (renamed to mlv_lite).

Enjoy and thanks to dmilligan for bringing it to life!
Title: MLV Lite
Post by: DeafEyeJedi on February 13, 2017, 04:37:14 AM
Big shout out and congrats to @dmilligan!
Title: Re: MLV Lite
Post by: Tao on March 15, 2017, 07:10:15 PM
Hi,

I need to get a .MLV lite file (former raw_rec) into a DNG series. MLVmystic, which I used becaue the raw_rec was removed, gets red stripes all over every frame.

What can I do to convert this ? I'm on Windows. I tried using MLVFS but the .exe doesn't work even with the other application installed. MLrawviewer crashes every time during the export to DNG.

Thank you
Title: Re: MLV Lite
Post by: domasa on October 07, 2017, 05:23:24 PM
How can I disable black frames in H264.proxy?

Video preview in Play mode is black, because first frame is black :-(
Title: Re: MLV Lite
Post by: dfort on October 07, 2017, 05:54:58 PM
It is black until you press play, then the movie will preview in camera.

I just wrote up something about H.264 proxy in the Switch app (http://www.magiclantern.fm/forum/index.php?topic=15108.msg191280;topicseen#msg191280) topic. That might help you understand how it works.
Title: Re: MLV Lite
Post by: domasa on October 07, 2017, 07:25:41 PM
Quote
It is black until you press play, then the movie will preview in camera.
Yes, I knew that. I usually shoot hundreds videos files... all will have a black previews. This is not usable.

Sometimes I do not need to record the sound. But I always need quick preview..
Title: Re: MLV Lite
Post by: dfort on October 07, 2017, 08:10:39 PM
Quote from: domasa on October 07, 2017, 07:25:41 PM
all will have a black previews. This is not usable.

Are you talking about previewing in the camera in the Canon "Play" mode? Are you saying that the problem is because the icon frame is black? Maybe a clever programmer (not me) can set the icon frame so it isn't black.

As you know after shooting hundreds of raw video files with H.264 proxy the MOV file is a little longer than the MLV file. These "handles" are black so you see only what was recorded in the raw video file. What's the point in playing back something that wasn't recorded in your MLV file?

I don't understand what you find "not usable."
Title: Re: MLV Lite
Post by: domasa on October 07, 2017, 11:11:57 PM
Quote
Are you talking about previewing in the camera in the Canon "Play" mode?
Yes. All thumbnails are black... This is problem.
Title: Re: MLV Lite
Post by: dfort on October 07, 2017, 11:33:58 PM
Here is the commit (https://bitbucket.org/hudson/magic-lantern/commits/489a20fbd1f1dc8e7ec1521d3c5caa5392966772) that set the H.264 proxy frame to black. Maybe there's a way to have just the first H.264 not black? Then of course apps like Switch that are looking for black frames at the head will have to account for this.
Title: Re: MLV Lite
Post by: ErwinH on October 20, 2017, 03:27:08 PM
I've been playing around with this module and mlv_snd for the last two days. My alterations are quite hacky, but at least they (kind of) do their job!

https://bitbucket.org/ehoutsma/magic-lantern/commits/7c5159775b6335f6134d500d47b790abb6f10ef9

Next steps: remove the hacky parts (fixing the samplerate at 48000) always assume the sound is enabled, maybe get a little better sync. Fix a lot of errors that aren't errors.
Title: Re: MLV Lite
Post by: Danne on October 20, 2017, 03:52:13 PM
Cool! Nice work.
Title: Re: MLV Lite
Post by: Danne on October 20, 2017, 04:25:11 PM
Tested briefly on the eos 100D. Didn´t create a wav file. Console saying something about  frame order error or similar:
Code: [Select]
ML ASSERT:
slots[slot_index].size < max_frame_size
at mlv_lite.c:3554 (raw_video_rec_task), task raw_rec_task
lv:0 mode:3
Title: Re: MLV Lite
Post by: ErwinH on October 20, 2017, 04:56:03 PM
Like I said, hacky and errors.

There should be an wavi block inside the mlv and if there is audio audf blocks.
Title: Re: MLV Lite
Post by: ErwinH on October 20, 2017, 08:52:51 PM
Most of the errors are because the checks are only made for video frames and this check validates the working of the compression.

The frame sequence error is a more a warning than an error.

These errors need fixing but should't stop the working of the combination of mlv_lite and mlv_snd and it should result in the same result as mlv_rec and mln_snd.
Title: Re: MLV Lite
Post by: Danne on October 20, 2017, 09:07:47 PM
What cam are you using to get the audio? On 100D with mlv_snd enabled with mlv_lite I get dng files but no wav from the MLV file.(14bit-lossless).
Title: Re: MLV Lite
Post by: ErwinH on October 20, 2017, 09:58:56 PM
700D but that shouldn't really matter. With this version of mlv_lite you should always get a wav file, because it's hard coded to add the wavi-header to the mlv file.

If you run mlvdump -v --skip-type VIDF |more, do you see a WAVI block after the WBAL block, and maybe AUDF frames?

You can also look for WAVI with hexdump. It should be in the first 1600 bytes.
Title: Re: MLV Lite
Post by: ErwinH on October 21, 2017, 10:17:51 AM
Which commit did you build,Danne? 42b544a or 7c51597.

If you have build 42b544a it is correct you didn't get the wave file. The variable is filled after the header is written. Second recording should contain the header.

Was already working  on a fix cq improvement. Will commit it later.
Title: Re: MLV Lite
Post by: Danne on October 21, 2017, 10:29:04 AM
Gonna check a little later. Busy. Stay tuned.
Title: Re: MLV Lite
Post by: ErwinH on October 21, 2017, 08:19:06 PM
The issue is that the values are shared with the recording module (mlv_lite and mlv_rec) after the audio recording is started. Depending on the moment of storing of the wave header, this is or isn't a problem.

In the mlv_lite I've added the wav header inside write_mlv_chunk_headers, which is called before the starting of the mlv_snd module.

At the moment I've moved the start of the audio recording to before the writing of the header. Not the best way. Alternative could be to move the sharing of the header to the raw_rec_cbr_starting call. I don't know if that will give issues with mlv_raw.

This solution doesn't work well with prerecord.

Haven't looked at the data corruption  /frame order consistency checks.
Title: Re: MLV Lite
Post by: Danne on October 21, 2017, 10:48:10 PM
It´s this branch right?
crop_rec_4k_mlv_lite_snd

Still not getting the actual wav file out of the mlv file from my 100D files. audf is in there:
Code: [Select]
Block: AUDF
  Offset: 0x087bad00
  Number: 112
    Size: 38656
    Time: 28.069000 ms
   Frame: #0000
   Space: 232
Block: AUDF
  Offset: 0x087c4400
  Number: 113
    Size: 38656
    Time: 228.578000 ms
   Frame: #0001
   Space: 232
Block: AUDF
  Offset: 0x087cdb00
  Number: 114
    Size: 38656
    Time: 429.834000 ms
   Frame: #0002
   Space: 232
Title: Re: MLV Lite
Post by: ErwinH on October 22, 2017, 09:20:48 AM
Yes, it's the crop_rec_4k_mlv_lite_snd branch.

I've found the issue. I wanted to store the HDR I received from mlv_snd and save it, but I'm having some issues with global variables. Will have to look into that later.

I've edited the routine and it builds a new header and saves it.
Title: Re: MLV Lite
Post by: ErwinH on October 22, 2017, 01:47:27 PM
The module mlv_lite is totally not written for integration with another source of content, audio in this case. There are a lot of consistency checks and other checks that assume the video frames are the only frames.

I've disabled a check (frame order consistency assert because the check doesn't work this way anymore) and moved a few checks to videoframe only.

Capturing is now working without asserts and warnings for frame order.

It should work on all the camera's the crop_rec_4k branch compiles.
Title: Re: MLV Lite
Post by: Danne on October 22, 2017, 02:47:52 PM
It works on the 100D :). And with latest branch of MlRawViewer you get audio and preview working with lossless footage:
http://www.magiclantern.fm/forum/index.php?topic=9560.msg191988#msg191988

Title: Re: MLV Lite
Post by: 12georgiadis on October 22, 2017, 02:57:58 PM
Quote from: Danne on October 22, 2017, 02:47:52 PM
It works on the 100D :). And with latest branch of MlRawViewer you get audio and preview working with lossless footage:
http://www.magiclantern.fm/forum/index.php?topic=9560.msg191988#msg191988
So now, no need for the H264 proxy method + switch for audio with lossless footage ? In any case, proxy H264 are still usefull for  preview and direct offline/online.
Title: Re: MLV Lite
Post by: Danne on October 22, 2017, 03:05:41 PM
Well as you say, proxy is still useful. Tested a few lossless 12bit files and worked fine.
Title: Re: MLV Lite
Post by: 12georgiadis on October 22, 2017, 04:07:09 PM
Quote from: Danne on October 22, 2017, 03:05:41 PM
Well as you say, proxy is still useful. Tested a few lossless 12bit files and worked fine.
Danne, you mean lossless with sound ?


Envoyé de mon iPhone en utilisant Tapatalk
Title: Re: MLV Lite
Post by: Danne on October 22, 2017, 04:19:54 PM
Yes.
https://bitbucket.org/Dannephoto/magic-lantern/downloads/
On top, audio build for the 100D. Briefly tested.
Title: Re: MLV Lite
Post by: ErwinH on October 22, 2017, 06:11:01 PM
Good to hear that it works, Danne!

Still have a few issues to tackle. Especially the callback from mlv_snd and have a good look at the consistencychecks.
Title: Re: MLV Lite
Post by: Danne on October 22, 2017, 06:33:06 PM
Of course, but a real good work in progress. Good work!
Title: Re: MLV Lite
Post by: IDA_ML on October 23, 2017, 12:49:15 PM
LISTEN EVERYBODY!!!
===============

Thanks to ErwinH's and Danne's efforts, we have reached a milestone:

The 100D can now record CONTINUOUSLY with SOUND in the 8...11 bit lossless mode at 24fps and 1728x972 resolution in the NORMAL and the MOVIE CROP MODEs.  The files occupy about 2 GB/min on the card which is not too bad.

This means that with the 100D and external power, we can now record an entire rock concert with sound and RAW quality.  This is absolutely amazing!  You guys are a magitions!  Keep up the good work!

--------------------------------------------

This is my impression after running the first few tests.  I encourage other 100D owners to test and share their experience too. I will also keep testing as soon as I find some more time for that.

A question to Danne:
-----------------------
Will it be possible to enable sound at 5x magnification too?  This is where we get this unbelievable image quality with the 100D at 2520x1080 resolution, unfortunately with some hick-ups that hopefully will be fixed soon.
Title: Re: MLV Lite
Post by: Danne on October 23, 2017, 01:12:28 PM
Not me IDA_ML, it´s all @ErwinH work:
http://www.magiclantern.fm/forum/index.php?topic=16650.msg191983#msg191983
Branch:
https://bitbucket.org/ehoutsma/magic-lantern/branch/crop_rec_4k_mlv_lite_snd
I only compiled a build for the 100D :)
Title: Re: MLV Lite
Post by: ErwinH on October 23, 2017, 02:10:04 PM
I've compiled builds for all the camera's that are supported by the crop_rec_4k branch. I haven't tested the 5D3 and 100D builds, but they should work fine.

https://bitbucket.org/ehoutsma/magic-lantern/downloads/

I've altered mlv_snd a little to send a callback to mlv_lite before starting the recording, or mlv_rec after starting the recording, so prerecording should in theory also work.
Title: Re: MLV Lite
Post by: Danne on October 23, 2017, 02:19:09 PM
Don´t forget the eosm :)
Title: Re: MLV Lite
Post by: ErwinH on October 23, 2017, 02:35:38 PM
Here you go!

Now let's bring in the feedback!
Title: Re: MLV Lite
Post by: Lars Steenhoff on October 23, 2017, 02:57:04 PM
Tested on 5d Mark 3 firmware 1.2.3

Results:

mlv_lite with sound enabled 14 bits compressed raw : sound is good
mlv_lite with sound enabled 14 bits compressed raw + h264 : sound is static noise.
Title: Re: MLV Lite
Post by: Lars Steenhoff on October 23, 2017, 03:12:28 PM
Sidenote :

I think it will be good to make the first frame of the h264 not black
for preview in the camera and in the finder. so the thumbnails are not black.

@Danne would you will be able to modify the scripts in switch to adjust for this if the would happen ?
Title: Re: MLV Lite
Post by: Danne on October 23, 2017, 03:36:44 PM
It´s mainly a question if it´s possible with the c-code but it´s also gonna be some tinkering cutting the first frame then compensate for that frame to match with the rest of the cut footage etc. Quite a few situations to start messing with which in worst case scenario could break the script. So maybe apply KISS here.
Previews works in camera although need to wait for the black frames to dissapear and in finder you can view the files after cutting them.
Title: Re: MLV Lite
Post by: IDA_ML on October 23, 2017, 03:52:44 PM
Quote from: Danne on October 23, 2017, 01:12:28 PM
Not me IDA_ML, it´s all @ErwinH work:

I am sorry, I missed that.  I have edited my post above and added ErwinH's name to the joint effort.

I forgot also to mention that the 100D MLV files with sound open and render nicely in MLV Producer v.3171 which is another bonus to all of us.  Render times to H.264 are really fast!
Title: Re: MLV Lite
Post by: Lars Steenhoff on October 23, 2017, 04:06:39 PM
yes with preview in cam I meant the thumbnails, sorry for the confusion.

It can be a bit difficult without a thumbnail to find a certain shot in camera when look to playback footage after a few takes.
I agree with KISS. I also keep in mind the use case of being on the road and needing to show and actor a shot from a few takes back.   :)

I was also thinking it may be good now that we get sound in mlv, to make the black frames of the h264 optional in a menu setting. 
this may solve my issue too. just need to generate the proxies afterwards in switch from the MLV if I still wanted to have the a proxy workflow afterwards.
Title: Re: MLV Lite
Post by: Danne on October 23, 2017, 04:12:04 PM
The black frames are cruicial to generate matched proxys in post. No match otherwise, but you knew that already :).
Title: Re: MLV Lite
Post by: Lars Steenhoff on October 23, 2017, 04:22:51 PM
yea I know, just thinking out loud.  8)

These are the options I came up with:

1. Make the black frames optional via menu setting.  no change required in post apps. we can use the audio from the mov and the mlv for syncing :)
2. Make first frame not black, may be difficult todo and need change in post apps
3. Do nothing

I prefer option 1 right now.
Title: Re: MLV Lite
Post by: ErwinH on October 23, 2017, 04:40:04 PM
I'd say, have a go at it :) That's the upside of Open Source. If you want something, you can do it yourself and share it with the community.
Title: Re: MLV Lite
Post by: Lars Steenhoff on October 23, 2017, 04:56:54 PM
Well here's the black frame commit from Alex, I just don't know yet how to make it a menu item.

https://bitbucket.org/hudson/magic-lantern/commits/489a20fbd1f1dc8e7ec1521d3c5caa5392966772?at=crop_rec_4k
Title: Re: MLV Lite
Post by: rob_6 on October 23, 2017, 06:11:37 PM
ErwinH,

Awesome! Is this intended to possibly work in 12 bit lossless and 3k mode? If so, I am happy to test it out. Thanks!

Rob
Title: Re: MLV Lite
Post by: 12georgiadis on October 23, 2017, 06:31:08 PM
Wow thanks ErwinH for the work!


Envoyé de mon iPhone en utilisant Tapatalk
Title: Re: MLV Lite
Post by: ErwinH on October 25, 2017, 03:08:21 PM
You're welcome. It's something I needed, glad it's of value for you guys too!

Audio isn't exactly in sync. I've done some testing and it's not even consistently out of sync, but it's only a few frames, so that's a quick fix.

I haven't tested any modes for recording, just a few simple 16:9 non crop 11..8 bit lossless recording with audio, but please try every single combination and post the results!

Regarding the preview image, isn't it an option to sync based on black frames at the end of the recording? Might take a bit more time in post processing, but at least you get to keep the preview images.
Title: Re: MLV Lite
Post by: Danne on October 25, 2017, 03:42:20 PM
Quote
Regarding the preview image, isn't it an option to sync based on black frames at the end of the recording? Might take a bit more time in post processing, but at least you get to keep the preview images.
Beginning and end of the file. Start H.264, then RAW. When raw starts the H.264 blackframes stops. At the end raw stops then H.264. Blackframes starts again after raw stops and then H.264 stops. This is my understanding.
Title: Re: MLV Lite
Post by: ErwinH on October 25, 2017, 03:47:01 PM
I was just thinking out loud. Looking for an alternative option for the h264 preview images. However the first frame as normal image shouldn't be to hard for the camera either. It's just the post-processing that's a bit harder.
Title: Re: MLV Lite
Post by: Lars Steenhoff on October 25, 2017, 03:49:58 PM
since we know the total amount of frames from the mlv file it should also be possible to caculate backwards from the last black frame right?

I still have to dig a bit more in the code of mlv_lite to see if I can manage to make a menu item with options. With my limited coding exoerience ( none really ) It may take a bit of time
Title: Re: MLV Lite
Post by: Danne on October 25, 2017, 03:54:31 PM
We don't know the exact amount of frames in the mlv file before it's spit out and indexed. There is a frames tag in the header but it's inexact.
Also note that H.264 blackframes varies in the beginning part. It's first after the beginning black frames are cut off that we can calculate the end part.
Title: Re: MLV Lite
Post by: dfort on October 25, 2017, 04:45:55 PM
About counting black frames from the end of the H.264 file.

Quote from: dfort on October 07, 2017, 05:42:00 PM
Out of four days of shooting that amounted to a few hundred clips and several hours (estimated about 300 shots, 4 hours) there were only two clips where the length of the raw footage didn't match up with the trimmed H.264 proxy. Being the perfectionist that he is Danne tried his best but the issue isn't with Switch--it turned out that sometimes the H.264 recording stops before the MLV. One short clip was off by 1 frame and the other, an 8 minute shot that spanned two H.264 files was off by 2 frames.

When the H.264 recording stopped before the MLV there were no black frames at the end of the H.264 file. Even though there is a mismatch in length, the current method of starting from the head of the clip keeps the H.264 and MLV files in sync and the editing software should have no problem re-linking between the proxy and raw files as long as you don't use the last frame of your raw fine in the edit. This shouldn't happen because you're making the creative editing decisions with the proxy files and the raw files are only for color grading, right?

The issue brought up by @ domasa is that the thumbnails in the camera are all black (http://www.magiclantern.fm/forum/index.php?topic=16650.msg191302#msg191302). This isn't a problem in the editing system because the black frames are trimmed of by the Switch application. Still, it would be nice to see proper thumbnails in camera if you want to check your shots in the field. This isn't a high priority item for me because when I want to playback a clip it is usually the last one I shot and that's what the Canon playback (a.k.a. review) will show. Note that with H.264 proxy there should be no need to playback the MLV files in camera so you don't need to turn on mlv_play.
Title: Re: MLV Lite
Post by: Lars Steenhoff on October 25, 2017, 04:53:03 PM
Besides the in camera thumbnails, I also can see the need for thumbnails on the computer since thats when I'm using to quickly identify a clip to review.
It would also be nice if .mlv files had a thumbnail image on the finder.  any idea if this would be theoretically possible to be generated by the camera ?
Title: Re: MLV Lite
Post by: IDA_ML on October 25, 2017, 07:18:15 PM
I have uploaded a MLV clip (about 700MB) shot with the 100D at 12-bit lossless compression + SOUND using the MLV lite module with FPS Override: OFF.  For those who wish to try, here is the download link which will be active for 7 days:

https://we.tl/shydYVJ0JV

I tested all options of the MLV Lite module with sound at the 1728x972 resolution and 23,97 fps and here is what I found:

1) At 8...11 bit LL video and sound are recorded synchronously and continuously;

2) At 12 bit LL video and sound are recorded synchronously and continuously;

3) At 14 bit LL video and sound are recorded synchronously but recording stops after about 450 frames;

4) At 10 bit uncompressed sound is recorded for about 3s and then stops while video continues recording until buffer is full;

5) At 12 and 14 bit uncompressed there is no sound at all; video recording continues until buffer is full.

My overall impression is that for short clips (up to 15 s.) synchronization between audio and video is perfect.  Audio and video tracks are of equal length. I did not test syncing at very long clips though.  Video quality is excellent, clips open well with the 32-bit version of MLVFS and grade well in DaVinci Resolve Lite on Win7x64!  There is no noticeable  quality degradation of the 8...11 bit LL mode vs. the 12 or 14-bit LL or uncompressed 10/12/14 bit modes.  Just the noise in the darkest areas at very high ISOs (3200 and 6400) looks slightly different but differences are very subtle.   The dark screen at 8...11 bit LL playback is also gone, (Thank you, A1ex!). Camera is very stable and I did not notice any crashes when switching modes.  The Movie crop mode works well too.  All in all, I am very pleased with the 100D at the 8 ... 11 bit LL mode with sound and think that now it is a very solid camera for RAW video recording with synchronous sound.  Excellent work from all developers involved!

Title: Re: MLV Lite
Post by: IDA_ML on November 03, 2017, 10:35:01 AM
Hello ErwinH,

After testing the 100D and reporting that it works very well with synchronous sound in the losslessly compressed RAW video modes (see my previous post above), I decided to check how it will work with the 5DMkIII.  I visited a friend of mine who has this camera and we tested the October 23-th build for the 1.1.3 FW that we downloaded from here:

https://bitbucket.org/ehoutsma/magic-lantern/downloads/

Here is what we found with the MLV-sound function enabled on the 5D3 with FPS override OFF:

1) In the end of each recording we get a red line on the screen saying "audio failed to stop".

2) Upon inspecting the recorded MLV file on a computer, cDNG converted with MLV-dump, we notice that the WAV-file is there with its full size but, when trying to play it, no sound comes out of the speakers.  The progress bar is clearly indicating that the WAV-file is being played.

3) The same behavior is observed also when recording in the 14/12/10 bit uncompressed modes in the MLV-recording module.  With the regular October 31-st nightly build, sound is recorded fine in the 14-bit mode MLV-recording mode.  No "audio failed to stop" message appears in the end of the recording. 

I was wondering if you may find some time to have a look at your Oct. 23-rd build for the 5DMkIII.  If the sound issue could be fixed with the lossless modes on this camera, this will boost its usability enormously!  Please let me know if you may need a .MLV file from the 5D3 that has this behavior.

Thank you again for your amazing work.

P.S.: If someone else with the 5D3 could confirm the above behavior, this would be helpful.
Title: Re: MLV Lite
Post by: JCut on November 03, 2017, 11:40:00 PM
First post!  :)  I've been using ML on my 6D for a couple years mainly for photos (checking raw histogram to ETTR), discovered how incredible ML raw video is, and bought a used 5D3 after hitting the SD slot limits of the 6D...

I'm currently using ErwinH's Oct23 build MLV Lite LL with sound on my 5D3, firmware 1.1.3, and it works for me.  I haven't experienced the issue reported by IDA_ML :

1.  I only tested with 12bit Loss Less, with MLV Sound working, continuous recording

2.  I can start/stop recording fine when recording @ 24p.  No errors/messages.

3.  I'm using MLVFS (32-bit - thanks to BouncyBall!) directly editing the MLV with Davinci Resolve 14.

4.  I also tried some crop mode recording in 1920x1080 @ 48p  and 1920x800 @60p , and it works with sound as well.  However, since I run it with realtime color LiveView, I get dropped frames after some time.  I noticed when editing those clips that stopped due to dropped frames, the sound cuts out a couple seconds before the the video cuts out.  I dunno if that could be related to the "audio failed to stop" message or not.

Thank you all for everyone's incredible work!  Magic Lantern keeps getting better and better!
Title: Re: MLV Lite
Post by: IDA_ML on November 04, 2017, 02:31:39 AM
Quote from: JCut on November 03, 2017, 11:40:00 PM
1.  I only tested with 12bit Loss Less, with MLV Sound working, continuous recording

4.  I also tried some crop mode recording in 1920x1080 @ 48p  and 1920x800 @60p , and it works with sound as well.  However, since I run it with realtime color LiveView, I get dropped frames after some time.  I noticed when editing those clips that stopped due to dropped frames, the sound cuts out a couple seconds before the the video cuts out.  I dunno if that could be related to the "audio failed to stop" message or not.

At what resolution did you test the 12bit Loss Less, with MLV Sound?  Did you also try the Crop mode at 3K and 24fps?  Could you also check the sound recording in the 14/12/10 bit uncompressed modes in the MLV-recording module?

I will ask my friend to repeat the tests on his 5D3, maybe with a faster CF card and see if he can get rid of the "sound failed to stop" message.

Thanks for your important feedback, JCut !
Title: Re: MLV Lite
Post by: JCut on November 04, 2017, 07:11:19 AM
Quote from: IDA_ML on November 04, 2017, 02:31:39 AM
At what resolution did you test the 12bit Loss Less, with MLV Sound?  Did you also try the Crop mode at 3K and 24fps?  Could you also check the sound recording in the 14/12/10 bit uncompressed modes in the MLV-recording module?

I will ask my friend to repeat the tests on his 5D3, maybe with a faster CF card and see if he can get rid of the "sound failed to stop" message.

Thanks for your important feedback, JCut !

Hi IDA_ML , I tested 12 bit LL with MLV Sound at 1920x1080.  (wider aspect ratios work also).  I didn't try out the 3K mode yet... However, I checked the sound recording in the 14/12/10 bit uncompressed modes in the MLV_REC module:

1.  14 bit uncompressed, 1920 x 1080 @ 24p - Sound works, no unusual messages
2.  12 bit uncompressed, 1920 x 1080 @ 24p - Sound works, no unusual messages
3.  10 bit uncompressed, 1920 x 1080 @ 24p - Sound works, no unusual messages

As for your friends "sound failed to stop" message, I'm using Sandisk Extreme Pro 160MB/s CF 128GB cards.  Does he have any other modules loaded ?  For Lossless MLV , I only have MLV_LITE, Crop_Rec, MLV_SOUND, and FILE_Man modules loaded, nothing else.


Title: Re: MLV Lite
Post by: Lars Steenhoff on November 04, 2017, 11:50:34 AM
Can you try also h264 proxy recording on canon 5dmk3?

I did get some sound issue with that. ( static noise )
Title: Re: MLV Lite
Post by: JCut on November 05, 2017, 01:42:47 AM
Quote from: Lars Steenhoff on November 04, 2017, 11:50:34 AM
Can you try also h264 proxy recording on canon 5dmk3?

I did get some sound issue with that. ( static noise )

Hi Lars,

I tried out the proxy recording lossless with sound, and I'm having similar problems as you.

1. 14 bit lossless, proxy record on = static on the sound file

2. 12 bit - same static

3.  I also experienced a different issue when proxy record was on. After a couple seconds the recording would stop and I would get a message "recording automatically stopped" or something like that. I also saw a red message flash briefly saying "sound failed to stop"
Title: Re: MLV Lite
Post by: IDA_ML on November 05, 2017, 09:42:45 AM
Thanks JCut,

I will send him your settings.  The problem could be that he is using a slower card and loading to many modules on it.  Did you test synchronisity between sound and video already?  That would be helpful too.
Title: Re: MLV Lite
Post by: Lars Steenhoff on November 05, 2017, 12:21:22 PM
Sandisk extreme 160MB,  128 GB.

The card is not the problem I think.

Proxy recording works well on the card with the normal mlv lite + h264 proxy
mlv lite + h264 proxy + mlvsound = static
Title: Re: MLV Lite
Post by: JCut on November 07, 2017, 09:03:07 AM
Quote from: IDA_ML on November 05, 2017, 09:42:45 AM
Thanks JCut,

I will send him your settings.  The problem could be that he is using a slower card and loading to many modules on it.  Did you test synchronisity between sound and video already?  That would be helpful too.

I'm currently on vacation, with no computer to check MLV files... But I'm recording lots of stuff with this mlv lossless + mlv sound build, so I'm crossing my fingers everything will be fine  ;)

I should be able to report back by this weekend!
Title: Re: MLV Lite
Post by: ErwinH on November 08, 2017, 11:13:37 AM
I've been using my 700D build to record with mlv lite + mlv snd and as far as I can tell the recordings are running smoothly, didn't ran into any issues.

I do get the Audio failed to stop "error", but that's not a real error. Recording is stopped, and audiometers continue to function. Might have something to do with that.

What's the reason why you want to combine h264 proxy with mlvsnd? h264 proxy has the same audio as mlvsnd (when recording at 48khz) so there's no reason to record it using mlvsnd.
Title: Re: MLV Lite
Post by: Danne on November 08, 2017, 11:52:04 AM
What´s the reason for Audio failed to stop "error"?

In mlv_sound.c
Code: [Select]
static void mlv_snd_stop()
{
    trace_write(trace_ctx, "mlv_snd_stop: stopping worker and audio");
   
    mlv_snd_state = MLV_SND_STATE_SOUND_STOPPING;
   
    /* wait until audio and task stopped */
    uint32_t loops = 100;
    while((mlv_snd_state != MLV_SND_STATE_SOUND_STOPPED) && (--loops > 0))
    {
        msleep(20);
    }

    if(mlv_snd_state != MLV_SND_STATE_SOUND_STOPPED)
    {
        bmp_printf(FONT(FONT_MED, COLOR_RED, COLOR_BLACK), 10, 130, "audio failed to stop, state %d", mlv_snd_state);
        trace_write(trace_ctx, "mlv_snd_stop: failed to stop audio (state %d)", mlv_snd_state);
        beep();
    }
MLV_SND_STATE_SOUND_STOPPED didnt work? Yet the audio stopped, but
Checking after the loop:
Code: [Select]
    /* some models may need this */
    StopASIFDMAADC();
    // SoundDevShutDownIn();  /* no model seems to need this */
    audio_configure(1);
Is this the stub that is working?
Title: Re: MLV Lite
Post by: Lars Steenhoff on November 08, 2017, 02:31:25 PM
@ErwinH

Reasons for proxy h264 other than sound:

- Realtime Playback of clips in camera after shot ( on set shot review )
- Using it in a proxy workflow - editing with the h264 and only sync them up in the color correction phase.
- easy to send someone the files after shoot to start edit because they are smaller.
- possible to transfer footage to ipad/phone for client review

edit i see you mean why sound on both!

well to have a quick sound preview with mlvplayer and to dont have to sync them up for preview

Title: Re: MLV Lite
Post by: 12georgiadis on November 08, 2017, 02:47:06 PM
Yes, with sound in both proxy and mlv, it bypasses a step in switch app and then save time
Title: Re: MLV Lite
Post by: dfort on November 09, 2017, 07:07:38 PM
That StopASIFDMAADC / SoundDevShutDownIn issue was resolved in the crop_rec_4k branch but the unified branch still has a hack where SoundDevShutDownIn is using the address for StopASIFDMAADC on some cameras. In order for audio recording to work on H.264 and MLV Lite simultaneously will probably require re-working mlv_snd and possibly requiring the SoundDevShutDownIn stub.

Recording sound in both the proxy and raw file may seem like a good thing in theory, in practice it doesn't really have much advantages. The black frames need to be trimmed off of the H.264 proxies in order for them to match the raw files. That step is necessary before editing starts or you will have issues later on. Switch can do this very quickly in the field as you're copying the files off the cards. Most people are probably processing their MLV files after the shoot so it should be no problem having Switch sync the audio automatically.

Speaking of theory and practice, it shouldn't be necessary to have the audio with the DNG files because you only need to conform the picture for color grading.
Title: Re: MLV Lite
Post by: 12georgiadis on November 09, 2017, 08:40:18 PM
Quote from: dfort on November 09, 2017, 07:07:38 PM
That StopASIFDMAADC / SoundDevShutDownIn issue was resolved in the crop_rec_4k branch but the unified branch still has a hack where SoundDevShutDownIn is using the address for StopASIFDMAADC on some cameras. In order for audio recording to work on H.264 and MLV Lite simultaneously will probably require re-working mlv_snd and possibly requiring the SoundDevShutDownIn stub.

Recording sound in both the proxy and raw file may seem like a good thing in theory, in practice it doesn't really have much advantages. The black frames need to be trimmed off of the H.264 proxies in order for them to match the raw files. That step is necessary before editing starts or you will have issues later on. Switch can do this very quickly in the field as you're copying the files off the cards. Most people are probably processing their MLV files after the shoot so it should be no problem having Switch sync the audio automatically.

Speaking of theory and practice, it shouldn't be necessary to have the audio with the DNG files because you only need to conform the picture for color grading.
Oh, I forgot about the black frames so you're totally right. One thing might be to have this proxy mode+snd available for all cameras that could handle it with mlv without sound (5d2, 7D, 700d, 6D, and 100D). I mean, when crop_rec_4k would work on both of them.
Title: Re: MLV Lite
Post by: Danne on November 09, 2017, 11:48:21 PM
Code: [Select]
Most people are probably processing their MLV files after the shoot so it should be no problem having Switch sync the audio automatically. Switch is prepared for the day that mlv_lite has audio. It will simply not extract audio into the dng folder when a wav file already is in there.
Producing the audio or even the cutting part of the proxy file is not that time consuming. What is taking time is the matching with the mlv file. Processing all dng files is neccessary for exact calculations.
Title: Re: MLV Lite
Post by: zachnfine on November 23, 2017, 10:53:54 PM
Hmm, I'm trying this with 5D113 firmware and "magiclantern-croprec4kmlvsnd.2017Oct23.5D3113", 3072x1308 12-bit lossless, and have made a few little recordings. I'm processing the resulting MLV files with the 11/7 version of 'switch'. Each time, I end up with a director full of nice-looking 3072x1308 dng files and a single wav file of 2k in size that's silent.

It's possible that the audio is just not getting properly recorded, but I don't know for sure that the audio isn't present just fine in the MLV file and that Switch isn't just having trouble extracting it. I'm not sure how to tell since I don't know the best, approved manner by which to extract audio ffrom MLV Lite recordings.
Title: Re: MLV Lite
Post by: zachnfine on November 23, 2017, 11:08:28 PM
Hmm, I tried the same file with mlv_dump.osx (a very old mlv_dump, dating back to 2014, since I can't seem to find a binary for the latest mlv_dump (searches just lead me to old forum threads). The result was a bunch of nice looking dng files and a 44-byte wav file that seemed to contain no data. I looked at both its contents and those of the wav file that Switch had generated and they both appeared to be pretty much content free, but the Switch version included some Blackmagic metadata that must be there for compatibility with Davinci Resolve.

So I guess I'm recording files with blank data.
Title: Re: MLV Lite
Post by: Danne on November 23, 2017, 11:21:39 PM
I don't think audio is working with crop modes.
Title: Re: MLV Lite
Post by: jankrueck on December 02, 2017, 12:08:52 PM
I came here, because someone was posting on the 4k branch :D
So still no sound for resolutions higer than HD ?
Title: Re: MLV Lite
Post by: 50mm1200s on April 19, 2018, 07:17:04 AM
I'm getting glitches :(
Setup is 50D crop_rec (3x), ML build from @dford, res 1920x1080 at 24fps. If you need any other info I can provide it...
Title: Re: MLV Lite
Post by: dfort on April 19, 2018, 07:52:11 AM
Quote from: 50mm1200s on April 19, 2018, 07:17:04 AM
I'm getting glitches :(

You mean the 10bit/12bit build?

Delete the ML settings and try from a fresh start. On both the 7D and 500D I found that it works the first time but you get "earthquake" video on restart. Hey, this is highly experimental stuff. Help figure it out.
Title: Re: MLV Lite
Post by: 50mm1200s on April 19, 2018, 09:38:53 AM
Quote from: dfort on April 19, 2018, 07:52:11 AM
You mean the 10bit/12bit build?

No, I mean the build you made on this (https://www.magiclantern.fm/forum/index.php?topic=21931.msg199618#msg199618) thread.

Quote
Delete the ML settings and try from a fresh start. On both the 7D and 500D I found that it works the first time but you get "earthquake" video on restart.

mlv_rec works fine (with crop_rec), but mlv_lite gives me the glitches. Indeed, the glitch is mostly when I start the recording and in the middle of the footage.

Quote
Hey, this is highly experimental stuff. Help figure it out.

Sure, as I said, if you need me to do any tests I can help. Everything seems to work normally (WB and black levels are ok), except for the glitchs:

(https://i.imgur.com/olPjRAw.jpg)
Title: Re: MLV Lite
Post by: lightspeed on November 03, 2019, 02:27:43 AM
was anyone ever able to get the lower bit rates to work with crop_record