Recording RAW and H.264 at the same time

Started by a1ex, February 11, 2017, 02:34:52 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


This is a great idea. Tested it and it works well. However, would it be possible to have the proxy h.264 recording together with the non-lite flavour of MLV (with sound).
That would make post-production syncing a lot easier. Thanks!


what about separating chroma channels to be recorded with RAW video? could it further cut the RAW video bitrate?

combining the chroma channels with the H264 compressed video in post, this should give better video quality for the slow write speed camera

quality between full RAW and H264, while giving longer record time perhaps.



As it currently stands, this isn't meant to be used as an online/offline proxy solution, right, it's more of a 'confidence check'? With the h.264 file starting before and ending after the raw, and having no option for timecode (unless with the 5D3 there is a way of ML 'reading' camera timecode I don't know about) there's really no current solution for re-conforming offline proxies to online raw in post, cierto? Not to mention filenames are different. But the h.264 file can be set to inherit timecode from the camera clock which ML has more than frame-accurate access to no?

Finishing a shoot, popping the SD card into a laptop, editing, and reconforming and processing only the needed ML clips would be quite the treat. The only camera that does this well for me currently is any DSMC2 body from Red and even then it's on the same media as the raw file which is less convenient. The lack of a simultaneous proxy solution was the one thing that kept me from buying an Ursa mini pro. Would be delightfully humorous if ML ends up being able to do this ;)


Quote from: erikbaldwinson on March 13, 2017, 09:21:54 AM
Is there the possibility of simultaneously deleting the h264 proxy and corresponding RAW file...?
It will be greate! Please do it.


@a1ex What would it take to get h.264 proxy working on the 5D mark 2?
Could you give me a pointer if it is not a difficult task ;)
If it is difficult, then I guess it can stay broken for some more time :(

I think it would be a good feature to put in to unified if it gets to a point where it works on all cameras ;)


Probably just troubleshooting it.

You could break the task into simpler ones, for example:
- can you allocate memory with shoot_malloc and/or srm_malloc during H.264 recording?
- can you record H.264 while the LiveView RAW stream is active?
- if not, is there any conflict over EDMAC channels? can it be solved by using other channels?
- does the raw recording code get stuck anywhere?
- if yes, find out where (using printf, NotifyBox, LED blinks, special effects or whatever else you find easier)
- anything unusual in Canon's debug messages? (warning: in LiveView, you'll get a few MB of messages within seconds, and you may have to reduce the FPS)


First step:
Quote from: a1ex on August 02, 2017, 09:02:54 PM
- can you allocate memory with shoot_malloc and/or srm_malloc during H.264 recording?

Ok I don't know if I'm testing correctly, but here's what I did (in the h264 proxy branch)
Added this in line 1699 of mlv_lite.c: (some original code left in for context)
    if (h264_proxy)
        /* start H.264 recording */

    struct memSuite * testmem = shoot_malloc_suite(20);
    if (testmem != NULL)
        NotifyBox(5000, "shoot_malloc success");

    //testmem = srm_malloc_suite(20);
    //if (testmem != NULL)
    //    NotifyBox(5000, "srm_malloc success");

Is this the right way to test successful memory allocation in ML? I hear stdlib isn't perfect in ML, so not 100% sure.
(I individually commented out srm and shoot and recompiled twice, both allocations seem worked)

I think I'll test this one next:
Quote from: a1ex on August 02, 2017, 09:02:54 PM
- does the raw recording code get stuck anywhere?
As it seems easier than these:
Quote from: a1ex on August 02, 2017, 09:02:54 PM
- can you record H.264 while the LiveView RAW stream is active?
- if not, is there any conflict over EDMAC channels? can it be solved by using other channels?


I tried this out about 2 mouths ago or so , if I remember right I had both h264 & raw enabled at same time but it defaulted to only h264 recording instead of both .
I see if I can find that build .


Ok it seems to get to
and freezes there... until I go to the trashcan, disable raw video, then stop it myself.

The line right after that is
"edmac"... sounds familiar...
Quote from: a1ex on August 02, 2017, 09:02:54 PM- is there any conflict over EDMAC channels? can it be solved by using other channels?
I'm guessing it must be an EDMAC channel conflict. Do you think this is the case?
... sorry to be bothering you again how do you change EDMAC channels?

EDIT: found it, changed the channels around within allowed range in the comments, did not seem to help. So I guess it might not be an EDMAC conflict.


You can use the "edmac" module to diagnose it. Find the free channels in standby mode (to cross-check the existing configuration), then see if anything changes while recording.


Hmm, you mean the EDMAC thing in the debug tab?
I looked at it, but don't understand what's going on.

Here's a screenshot while recording h.264 (no RAW):

Here's it in liveview not recording:

Doesn't really make much sense to me :-\


Yes, that EDMAC thing was recently moved to a module (check the current nightly).

Unfortunately, the "Find free EDMAC channels" tool does not work while recording, as it goes to PLAY mode whenever the tested channel is busy (that's because in PLAY mode, all channels are free). It might work if you use PauseLiveView instead, but that one must be forwarded to a different task (because check_timeout runs on interrupt, not on a regular DryOS task).

Background info:

On this screen, [] are channels and <> are connections.

I should probably draw a diagram, based on my current understanding (which can be found as "executable documentation" in the QEMU branch).


I downloaded latest nightly - there was no, maybe there's a build error happening?

As it seems finding free channels automatically is troublesome, might have to try and hand pick some more channels next time and see if that works.


Quote from: Ilia3101 on August 05, 2017, 07:52:40 PM
I downloaded latest nightly - there was no, maybe there's a build error happening?

Yeah, that's why these things are under review for some months, until nobody bothers to look at them :D


I just tested H264 proxy with sound + 1080p compressed raw and it works perfectly. However h264 are longer. to sync h264 proxy + sound + 1080 raw, I tried to determine the offset. It is around 2s but not regular. Sometimes +1i or 2, sometimes -1i or two. Is there a way to have a stable offset ? If yes, a simple ffmpeg script could sync everything.


There is an idea from a1ex about synching H.264 and raw stream by starting off with a black frame(both raw and H.264) when H.264 starts. Can't find the link. I thought it was a cool idea.


And the black frames appear together Both on h264 and raw ? With the same number of iframe ? It sounds interesting

Envoyé de mon iPhone en utilisant Tapatalk



Can we have more details with the black frame sync method ? If there is an auto-sync solution, that would Be awesome and very usefull with compressed raw! :) thx

Envoyé de mon iPhone en utilisant Tapatalk


Made some tests on 700D:

-Activating RAW stream in mv1080 (without RAW recording) while recording H.264 makes LiveView choppy and this affect the recorded H.264 video, changing EDMAC channels doesn't help (same result, beside H.264 recording doesn't use EDMAC channels which we are using, the problem isn't with EDMAC channels because continue reading)

-Recording H.264 proxy with uncompressed RAW video in mv1080, H.264 video would be choppy with some pink frames in the beginning and in the end, RAW video have 50% corrupted frames, 50% frames looks fine (something like that), lowering RAW video resolution might help a bit but not much, in lossless compression RAW data is completely corrupted and recording stops after ~4 seconds

-Well, in mv720, FPS override to 25 FPS, H.264 proxy works just fine with uncompressed RAW, LiveView is smooth, H.264 video is just fine (doesn't have choppiness or pink frames in the beginning or in the end), RAW video also fine, no corrupted frames, but with lossless compression same result (RAW video is completely corrupted, recording stops after ~4 seconds), this explains that EDMAC channels aren't the problem

-Canon H.264 buffer alert comes after some seconds after starting recording RAW video with H.264 proxy (mv720 @ 25 FPS), the recording stops after ~14 seconds, lowering RAW resolution or FPS don't affect the ~14 seconds recording time, also we didn't reach SD card write speed limit (so the write speed isn't the problem here)

-In mv1080 1736x1158 * 24 FPS RAW data being processed in LiveView vs mv720 1736x696 @ 25 FPS RAW data being processed (more memory + memory bandwidth being used in mv1080)

-So it's probably memory allocation problem, the area of RAW data stream in memory which affects H.264 stream, or it might be just memory speed isn't fast enough for RAW data and H.264 proxy in mv1080 (well, I don't think it's a really memory bandwidth problem, continue reading)

-Using FPS override in mv1080 @ 4 FPS then recording RAW data with H.264 proxy have same problems as in mv1080 @ 24 FPS --> it's clearly not the memory bandwidth

-I don't know how to change allocation area yet


I tried it on the 5D MKIII using the 4K crop mode experimental build, (magiclantern-crop_rec_4k.2018Jul22.5D3113)  and I am having the following issues:

1) I can only record by setting the resolution in the Canon menu to 640x480. This would be absolutely fine, as I mainly want it a s a proxy for playback in the camera, except  that:
2) The sound is corrupted. The raw / MLV sound is blown to maximum, so just a loud hiss even when set the recording volume to just one or two, and there is no sound at all in the proxy file.

Does this work properly on another build or am I just doing something wrong?