MLV Lite

[Danne]

Yes, padding, remember dmilligan,s solution from before.
Anyway. Tested push and working.
Thanks.

[a1ex]

This module is now available in the nightly builds (renamed to mlv_lite).

Enjoy and thanks to dmilligan for bringing it to life!

[DeafEyeJedi]

Big shout out and congrats to @dmilligan!

[Tao]

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

[domasa]

How can I disable black frames in H264.proxy?

Video preview in Play mode is black, because first frame is black :-(

[dfort]

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 topic. That might help you understand how it works.

[domasa]

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..

[dfort]

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."

[domasa]

Are you talking about previewing in the camera in the Canon "Play" mode?

Yes. All thumbnails are black... This is problem.

[dfort]

Here is the commit 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.

[ErwinH]

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.

[Danne]

Cool! Nice work.

[Danne]

Tested briefly on the eos 100D. Didn´t create a wav file. Console saying something about  frame order error or similar:

Code Select Expand

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

[ErwinH]

Like I said, hacky and errors.

There should be an wavi block inside the mlv and if there is audio audf blocks.

[ErwinH]

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.

[Danne]

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).

[ErwinH]

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.

[ErwinH]

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.

[Danne]

Gonna check a little later. Busy. Stay tuned.

[ErwinH]

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.

[Danne]

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 Expand

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


[ErwinH]

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.

[ErwinH]

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.

[Danne]

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

[12georgiadis]

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.