#171 Melt / MLT play OGV/WebM's incorrectly, losing sync

[Zoopy]

ERROR DESCRIPTION:
I've been getting a sync error with Kdenlive, and after meticulous testing of FFMPEG, MLT and Kdenlive, I've tracked it down to MLT.

Specifically, I created a wav (output.wav) that plays a tone for 3 frames (24 fps) at the start of every minute for 10 minutes. Then I created a file in Kdenlive that is entirely a black clip, but with 3 frames of white at the start of every minute and render it to an ogv (output.ogv). If I import those 2 into a new instance of Kdenlive, they are out of sync.

Why do I think it's MLT? Well, when I play output.ogv in ffplay it looks as expected. The first three frames of each minute are white. When I play output.ogv with "melt output.ogv" I get a very different result. Specifically, the first time through the following frames where white:

0,2,10,16,21-76

More disturbingly, when I went backwards and forwards, particularly in frames between 10-21, they would frequently change between white and black, usually when I'd hit another frame that consistently showed as one of those colors. It was almost as though some frames just didn't update. When rendered in Kdenlive, the result looks the same as in Melt. In Mplayer the video plays correctly, as it does in ffplay.

STEPS TO REPRODUCE:
1. Play output.ogv
2. Note that many frames are white other than the first three of each minute and that the white markers drift out of sync over time.

EXPECTED BEHAVIOR:
Melt keeps video in sync, resulting in 3 frames of white flashing at the start of each minute.

[Zoopy]

Output.ogv (should be all black, except 3 frames of white at the start of each minute)

[Zoopy]

PS I've marked it as being in MLT++ and not just Melt, as the error occurs when using Kdenlive, which I presume uses MLT directly.

Error occurs on both 32 and 64 bit versions, across both Chakra Linux, Kubuntu and Ubuntu. I tested both 0.7.6 and current git master of MLT / Melt (compiled with the Kdenlive build script).

Playback of Mpeg2 and RealVideo works fine. Interestingly WebM also displays the exact same error as OGV.

[Zoopy]

AVI using FFV1+flac also works fine.

[Dan Dennedy]

I rendered a special A/V sync test clip I have to _Ogg_Theora_with_Vorbis_ using melt, and I reproduce the problem when seeking within melt. However, I also reproduce the problem upon seeking within ffplay (click around in video window). Moreover, when I use ffmpeg command line utility to transcode it, the sync is also lost upon playback within ffplay after seeking. If FFmpeg cannot support it correctly, then neither can MLT. Simple sequential playout does seem to maintain A/V sync based on my short tests (both melt and ffplay). This finding is based on FFmpeg git head as of a few days ago.

It should also be noted that other Ogg Theora files I have, for example Big Buck Bunny, are maintaining sync in melt after seeking. Also, when playing back an ogg created in ffmpeg or melt, I get many errors reported by libavformat:

[ogg @ 0x2416ea0] Broken file, non-keyframe not correctly marked.

I am closing out the Ogg Theora portion of this as non-fixable, and I will look at WebM next.

[Dan Dennedy]

Regarding the fact that other Ogg Theora videos seem to seek and sync fine, I was implying that other libogg-based tools may output fine, and it looks like there is a problem in the libavformat ogg muxer.

[Dan Dennedy]

WebM benefits from the use_pts=1 property; otherwise, A/V sync is off by several frames:

melt the.webm use_pts=1

There are heuristics for choosing an A/V sync strategy, and currently the logic selected by use_pts=1 is only enabled for H.264, but I can also set it if the video codec is VP8. I only have a couple of other webm files that I tested with that change, and they seem to work fine if not better.

[Dan Dennedy]

webm is fixed in git commit 99fe0ab.

Please do not add information about any other formats to this bug. I will close this ticket on the next release.

[Zoopy]

Ok. Appologies for adding info about the other codecs. I was trying to make sure the data I gave you was as complete as possible, but now I see that it was actually two separate issues.

So would I be right in guessing that your advice on the Theora issue would be to file a bug with the FFMPEG folks?

[Dan Dennedy]

Closing this because there is new release including the fix.