Mlv lite EDMAC timeout

Started by qqqavi, February 13, 2018, 11:06:23 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

qqqavi

Hi everyone,

I'm using MLV Lite with an external monitor (no Force VGA is set, with clear all overlays set when recording)  and when I hit record, it stops pretty often. I get EDMAC timeout error. Does anyone know why?

I use Canon 7D with the last built.

Thank you.


Enviado desde mi iPhone utilizando Tapatalk

a1ex

Most likely, the bandwidth required for all these tasks is more than DIGIC 4 can handle.

If that happens at 24 FPS, I'm afraid there's not much you/we can do about it.

qqqavi

Quote from: a1ex on February 13, 2018, 11:07:05 AM
Most likely, the bandwidth required for all these tasks is more than DIGIC 4 can handle.

If that happens at 24 FPS, I'm afraid there's not much you/we can do about it.

Thank you for your reply. I'm using it at 24fps (no sound). Isn't Mlv lite supposed to use less bandwidth because there's no sound, less metadata and no overlays? I'm telling you that because normal MLV Raw works just fine (however I get tearing when no force VGA is set).


Enviado desde mi iPhone utilizando Tapatalk

a1ex

That's because the regular mlv_rec does not attempt to detect this condition (so it doesn't print the error).

Bandwidth is the amount of data processed in some fixed amount of time. If you record at the same resolution, you get the same bandwidth (+/- some minor differences from slightly different file layout, unlikely to be relevant - on the image processing side, there are no differences in the amount of data processed).

qqqavi

Quote from: a1ex on February 13, 2018, 11:59:10 AM
That's because the regular mlv_rec does not attempt to detect this condition (so it doesn't print the error).

Bandwidth is the amount of data processed in some fixed amount of time. If you record at the same resolution, you get the same bandwidth (+/- some minor differences from slightly different file layout, unlikely to be relevant - on the image processing side, there are no differences in the amount of data processed).

Ok. Maybe it might sound like a stupid question, but I assume that there's no way to to "bypass" it?


Enviado desde mi iPhone utilizando Tapatalk

a1ex

The code is open source, feel free to modify it as you see fit.

qqqavi

Quote from: a1ex on February 13, 2018, 12:08:49 PM
The code is open source, feel free to modify it as you see fit.

I don't have that knowledge. ;)


Enviado desde mi iPhone utilizando Tapatalk

qqqavi

Quote from: a1ex on February 13, 2018, 12:08:49 PM
The code is open source, feel free to modify it as you see fit.

One more question: the error only shows up on the screen at the begging of the recording. Once the recording successfully starts, It never shows up after. Why's that? Thank you.


Enviado desde mi iPhone utilizando Tapatalk

a1ex

You should have mentioned that first, along with some more details.

For example: when you don't get the error, are the recordings always clean?

If yes: something in ML might overload the memory bus when recording starts (possibly too many things happening at once)
If not: the error detection for this condition might not work very well (this check was added to troubleshoot corrupted frames) or the bad frames might be caused by something else.

When you do get the error are the recordings clean or do they have bad frames? Repeatable? Happens most of the time? Totally unpredictable? How bad are the frames?

Cannot answer why exactly it happens - we are programming an undocumented system that controls hardware. The exact behavior of this hardware (in particular, under unusual conditions) is mostly unknown. Furthermore, the way you use your camera is very likely very different from what we do.

qqqavi

I've just done some tests with interesting results:

Canon 7D, Nightly.2017Dec07.7D203
Connected to my HDMI Monitor
Res: 1728x972
16x9
23.976fps
MLV Lite
No sound

Now comes the interesting part:

TEST1
Global Draw - On, All modes
Only Histogram Activated
Force HDMI-VGA - OFF
Clear Overlays - OFF

RESULT: Recording fails all the time (EDMAC timeout error).

TEST 2
Global Draw - On, All modes
Only Histogram Activated
Force HDMI-VGA - OFF
Clear Overlays - Recording

RESULT: Recording fails sometimes. However, if it successfully starts, it records continuously. No bad/corrupt frames. However, more test has to be done. No tearing.

TEST 3
Global Draw - OFF, All modes
Force HDMI-VGA - OFF
Clear Overlays - Recording

RESULT: No fails. Records continuously. No bad/corrupt frames. However, more test has to be done. No tearing. However, when I accidentally pressed the "ISO" button, the Canon menu showed up and the recording stopped. Conclusion: Looks like every time some kind of overlays are activated, recording fails. As you said, seems like  "ML might overload the memory bus when recording starts" and recording fails.

Hope this was helpful. Thanks again for your support.


a1ex

Right - ML overlays (in particular, zebras, histogram or anything else that does image processing) are a bit CPU-intensive.

Recommendations:
- fast zebras (these use no CPU, as they are computed by the display hardware)
- enable DIGIC peaking (again, no CPU is used, as the same display hardware computes it)
- disable histogram (although it's running as a low-priority task, it does crunch some data)

The above configuration still uses more CPU than with Global Draw off, but might work (not tested).

qqqavi


Lant3rz

taking notes on this too. thanks for the info