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

[g3gg0]

thanks.
nothing as simple as that.

should be fixed, can you try?
(re-record a new movie)

[1%]

Better but wavs are coming out 1KB with these logs:

http://pastebin.com/KVTEhUwG

http://pastebin.com/4dL3FBSV

Ok, undid the fix 1/2 way and now they have sound + dump... that block never gets written for some reason otherwise.

http://nitrobits.com/file/1lvTdJN2EcZv0Og/magiclantern-Tragic.2014Jan03.6D113.zip

[g3gg0]

Better but wavs are coming out 1KB with these logs:

that is absolutely correct as the mlv doesn't have any wave.
you said that the asif didn't shut down correctly.
so it doesn't start the second time and we get no audio....

[1%]

Yea but I fixed that, no more error message, correct # of frames with audio in the log but then 1KB wavs as the AUDF header was never written any time. Undoing 1/2 the overflow fix made it work and not produce 4gb wavs nor 1kb wavs.

[michael84]

Did some further tests with Sound recording on the 7D, this time with an external mic plugged in. So far, i can get continous recording at 1728x972 and 25 fps. When i reach 1 minute, the buffer suddenly begins to fill, and the recording stops at around 1:03 to 1:04 each time (no skip allowed). This coincides with reaching the 4 GB limit and file splitting. Either my card is too slow to catch up after the momentary writing speed drop at file split, or there is still the same bug others have been reporting.

Both with and without fps override (set at 25 fps exact) the timebase of the video is 100% correct compared to a clock, at least for the 1 minute+few seconds intervall i am able to record. I imported the files in Resolve lite, and set the project at 25 fps. No worries here.

The audio is perfectly in sync, both checked against the ticking of the clock an several flashes fired next to the mic throughout the recording. I got only one video with a 6 second longer audio file than the video, this was one i recorded until the camera stopped. The other files, where i stopped just before the buffer was full, i only get a few frames to much audio. Because the sync is ok, i guess the audio recording does not stop exactly simultaneous with the video. However, compared to the hassle external sound recording witout any in camera audio for easy matching in post, i can perfectly live with that little imperfection.

Now i need to develop a workflow, i guess i will try a conversion in ACR with the VisionLog Profile into DNxHD 10 bit, and grade the footage in AE or Premiere, perhaps using VisionLog LUTs. My machine is too slow to work directly with DNGs, and i want to use ACR for conversion, as Resolve Lite has no noise reduction and feels rather non intuitive to work with. Too bad that ACR has these flicker issues, it would be easy to get a nice look in it quickly, without having to use any LUTs later.

Next thing to test will be the 24p mode, although i probably wont use it here anyway. In PAL land, 25p is the way to go, i think, unless you plan to print your work to cine film.

[g3gg0]

Yea but I fixed that, no more error message, correct # of frames with audio in the log but then 1KB wavs as the AUDF header was never written any time. Undoing 1/2 the overflow fix made it work and not produce 4gb wavs nor 1kb wavs.

fixed that. you should now be able to pull my version.

@all:
updated the mlv_snd module and mlv_dump which had problems since the last change to allow long path names.

[g3gg0]

Either my card is too slow to catch up after the momentary writing speed drop at file split, or there is still the same bug others have been reporting.

yeah, i am aware of this. its due to the filesystem catalog being locked etc.
i am experimenting to work around this.

The other files, where i stopped just before the buffer was full, i only get a few frames to much audio. Because the sync is ok, i guess the audio recording does not stop exactly simultaneous with the video.

yes, thats the reason - audio and video cannot stop perfectly in sync.
well it could - then i would have to configure one audio buffer per frame duration. (40 ms @ 25 fps)
and this would cause a little more cpu load what i tried to prevent. (i use 200 ms buffers)

right now you have between 200 ms and 400 ms of additional audio data, which is 8 to 16 frames with 25fps.
one thing i could to is dropping the last audio frame, which would produce 200ms less audio data.
so we end up with 0 ms to 200ms of additional data. (0 to 8 frames)
but to be honest, i prefer having a bit too much data than too few


hmm i have read reports that said their audio start is 2-3 frames off.
so you are sure that the audio is perfectly in sync on 7d?

[1%]

I doubt any are in sync perfectly.... would be interesting to see a black frame + FFFF or something in the audio injected at the same time, begining + end.

[g3gg0]

why do you doubt?

we can not inject black and FF hardware-synced.

[1%]

I doubt because all of the wavs I've had from any canon always seemed like they started at a similar time, not necessarily frame 0/1 and have been the wrong length... if slated though and sometimes stretched it would line up however. Interestingly too if one camera is recording wav and another records videos the files were much easier to sync and didn't seem to have any stretch....

I guess if its not hardware synced any kind of built in slate would be useless, probably why I had no luck going that route.

[g3gg0]

I doubt because all of the wavs I've had from any canon always seemed like they started at a similar time, not necessarily frame 0/1 and have been the wrong length... if slated though and sometimes stretched it would line up however. Interestingly too if one camera is recording wav and another records videos the files were much easier to sync and didn't seem to have any

the reason why audio is recorded longer than the video is, i already explained there
this is no bug or problem, mlv_snd just recording 200-400ms longer. there is no need to stretch.

about the start time, i dont quite understand what you wanted to explain.

[1%]

When I tried to inject frames to sync with and beep into the audio, it would start at the same time but it wasn't frame 0.

[g3gg0]

i still dont understand what you wanted to say, nevermind

well, at least the people report that wav is in sync.

[1%]

lol. just that the start is consistent but not at the exact begining of the video.

[g3gg0]

here is an experimental version that *could* be better regarding buffer drops on file switching.
can some of you test it?

[1%]

Recorded for 2 mins with the previous incarnation on 6D, didn't get a speed drop when the file split. Still split on an exfat card.

[michael84]

hmm i have read reports that said their audio start is 2-3 frames off.
so you are sure that the audio is perfectly in sync on 7d?

At least so far i can tell with my method. I fired an EX-430 remotely while recording, and looked frame by frame wether the Flash in the picture lined up with the discharge pop in the audio track. Every time it matched exactly. So unless the pop and the visual flash did not occur at the same time (will check this later with my HDR-FX1, just to be sure), the sync has to be ok, otherwise i would certainly be able to see it. Flash duration is only one frame. There is no sync drift over 1 minute recording.

However, what does happen is that the first few frames (2-3 could be just right) are not usable due to some kind of high level noise (waveform starts with a spike then drops to normal level). This is consistent through multiple recordings. So no offset, but some few frames of unusable audio. Note that this observation is only for 25p (selected in Canon menu /with and without 25 fps override selected, not 24p test yet), so for other modes there might be an offset/sync error.

I will try the experimental mlv.rec later. Amazing to see how much progress has been made recently, with updates rolling in on a daily basis. Keep up the good work!

[Jakobmen]

here is an experimental version that *could* be better regarding buffer drops on file switching.
can some of you test it?

16:9
1920x1080 after 1min in it starts the buffer bars go crazy then it skips. once with GD on and off

1856x1944 samething like above.. once with GD on and off

1728x972 recorded 5mins+ fine.. with everything on

Thanks g3ggo

[michael84]

Tested the new mlv.rec with my 7D, i can now record past 1 minute without frame drops. This time, sync was off by 2 frames, the audio was 2 frames before the picture, while the audio start (waveform peak) appeared to be 3-4 frames late. Now i will try again using the old mlv.rec, to see wether the sync issue is caused by the new mvl.rec, or just some inconsistency by the camera.

[budafilms]

Help: How can open MLV file in Apple Macintosh?

[Walter Schulz]

http://www.magiclantern.fm/forum/index.php?topic=8447.0

[Steve Kahn]

"Please contact g3ggo with this info:

Exception of type "System out of memory Exeption was thrown
at mlv_view_sharpVLVHandlerBlock(Sting type, mlv_rawi_har_t header,
Byte(} raw_data, Int32 raw_pos, Int32 raw_lwngth)






Also, on this same day shoot about half of the mlv files had no sound for some reason. 

[1%]

7D, 1728x1036 + internal mic is continuous for me now. Nothing is happening when going over the 4gb hump. GD off though

[Shield]

Sorry I haven't read this entire thread (planning to tonight) - Using the 5d3 + 1000CF KomputerBay + 32GB Sandisk I'm able to extract files fine and I get raw and audio.  My only question is this - when I set it to 1920x1080 in raw and have the MLV option enabled, I lose global draw (my sweet focus peaking is no more).  If I toggle the MLV recording off and restart the camera everything is fine.  Before you all yell at me, is there something simple I'm missing?
Thanks!
Shawn

[ted ramasola]

if I would dare guess that the mkIII is the same in MLV menu as the mkII then you go to MLV menu  and turn DISABLE G.DRAW to ON.

I know, its mislabeled and I was wracking my brains as I thought turning it on would do as it say, but it actually does the opposite and DOES NOT turn Gdraw off when it is ON.

Hope a developer can change this.  I already reported this in an earlier post #1093.