Messages

Devs - An Observation on Cut-Up/Pink-Frames

I've been using ML Raw Video (raw rec) on a 7D and find it is hard to totally eliminate the occasional cut-up / pink frame:



If recording with Global Draw on, I get approximately 1 bad frame per 1000 good frames.  Not a lot, but enough to be annoying to edit out.  Turning off Global Draw reduces but does not totally eliminate it.  Looking over a number of the videos, I have realized the cut-up/pink-frames are ALWAYS ON ODD FRAMES (with the first frame in the sequence being frame zero). 

Diving into the code (raw_rec.c), this corresponds to transfers from the ML allocated memory buffer used in the liveview double-buffering scheme (i.e. fullsize_buffers[0]) as opposed to Canons' buffer (full-size_buffer[1]). 

I don't know why the ML allocated memory would be more more prone to corrupt frames than the default Canon buffer - but it seems like it is. 

As an experiment, I simply changed the code to eliminate the double buffering.  The Canon buffer is used by default and I removed the call to raw_lv_redirect_edmac().  I have looked at over 30,000 frames taken with this change while running with Global Draw on, Histogram on and Spotmeter on - mostly non-cropped (but some cropped) at 24FPS, 1728*972.  Not a single cut-up/pink-or-corrupted-frame yet.

Given this, I am wondering whether double-buffering is strictly needed.  At the end of the day, the liveview buffer on average needs to get offloaded before the next vsync cycle.  As the transfers are executed off-CPU (by EDMAC) and the transfers are set up within callbacks (are these done within the context of interrupts?) - even with a busy CPU, they should be able to complete reliably in time.

So I am looking for any feedback from the devs on this.  Was double-buffering added to solve a specific problem (that might now have been addressed by more sophisticated FIO buffering)?  Is this likely to be a 7D-only fix with other models requiring the double-buffering? For sure I need to do some more testing with larger resolutions, 30 FPS, etc.

Thanks



.

Raw recording has been really solid for me.  Solid enough, in fact, that I started to feel all the memory buffer graphs and messages that flashed on the screen where unnecessary and distracting from the job at hand.  I pulled down the code and changed the display to something more compact:



Whenever recording, it displays the movie camera icon, the time recorded, the MB/s saved and idle time.

If the buffers start to get low, the color of the icon changes.  Yellow for anything other than "continuous OK":



and red for less than around 10 seconds to go:



and, if skipping is enabled, that is displayed too:



I would love to get any feedback or ideas on how to make this better.  As a newbie I did not want to barge in and start changing stuff, but if there is interest I could could submit a pull for raw_rec.c

The indicator is nice, but I wish it was even more out of the way and off the image. Having stuff in the image can be a problem, especially when it hides a boom mic in the shot.

How about using the bars for the main recording indicator, including the color treatment for buffer stress?  http://www.magiclantern.fm/forum/index.php?topic=8539.msg80890#msg80890

Good points, for sure.  I briefly looked at this when I first implemented, but the menu bars do not display when Global Draw is turned off to get extra write speed (which I think a number of users with slower cameras/cards are doing?)  There are probably a couple of options here:
- Allow menu bars to draw with Global Draw off.  I am guessing they use less CPU than the other things that are switched off such as histogram calculation and there are other highly useful bits there like the thermometer.
- Decide based on the Global Draw setting whether to put the indicator in the menu or draw it directly.  Since most use is probably 16:9 or wider aspect ratios, there is probably no need to have this in the picture regardless.

Feedback on any of this appreciated, I'll look at this tonight.

Hi m1Ke , How could I get a build where was the camera icon indicator???

hdclip - I think this is now in the nightly builds - you could look here: http://tl.bot-fly.com/ - the usual warnings about this being untested alpha code apply.

The indicator is awesome. There should be a choice between the buffer display and the compact one however. On cams with piddly buffers you may want to see whats going on. Also would help people who have slower cards when they're testing resolutions.

Maybe only needs the buffers on/off

I didn't want to add to a proliferation of menu entries if it was not useful.  There is a #define in the code which enables a menu entry to turn all the old messages/displays back on.  I can turn that on and tweak the code a little so it only displays the buffers and not the info that is redundant with the new indicator.

me3

Thanks guys.  I will submit this over the weekend (at the day job now).  One newbie question: having a 7D I have been copying One Percent's Tragic Lantern version down for my builds.  Should I create a branch on that and submit a pull request or should I create a branch off the main Magic Lantern tree? 

Sounds like you're not updating the sym file.

Yes, same thing was happening to me until I figured that out, d'oh!

[all]

If you know the free space before you begin recording and the image size and framerate, could you calculate the number of frames you have room for and stop the recording just before that?

Yes, you only have to keep track of all FIO_WriteFile calls (maybe also FIO_RemoveFile).

Or figure out how to ask Canon code to recompute the free space.