[FFmpeg-devel] [PATCH] matroska in VFW compatibility mode stores dts not pts as timestamps

[David Conrad]

On Mar 3, 2010, at 5:53 PM, Michael Niedermayer wrote:

> On Wed, Mar 03, 2010 at 10:51:48PM +0100, Aurelien Jacobs wrote:
>> On Mon, Mar 01, 2010 at 10:44:58PM +0100, elupus wrote:
>>> Hi,
>>> 
>>> Posted about this in the past
>>> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-November/038672.html
>>> 
>>> Anyway, here's an updated patch and a sample in incoming which shows the
>>> problem with ffplay.
>>> 
>>> filename: xvid-ac3-broken-timestamps.mkv
>> 
>> OK. Patch looks good and actually fix this sample. So applied.
>> I hope that all files encoded in VFW compatibility mode actually use
>> this scheme.
> 
> did our muxer follow it? if not then you have work to do, shouldnt be too hard
> though, out of order timestamps -> certainly pts

No, but I'm pretty sure we always used the native ID for any codec that could be out of order.

> BTW, I guess our matroka muxer also needs to be updated to store dts
>> in this compatibility mode ? (patch welcome...)
> 
> is that compatibility mode mandatory? or can things be stored without
> it? because storing just dts is really silly

Anything without a native id has to be muxed that way. And actually the spec implies that the timestamp should always be pts, but obviously other muxers don't follow this for VFW mode (or dirac...)

Quote:

Frames using references should be stored in "coding order". That means the references first and then the frames referencing them. A consequence is that timecodes may not be consecutive. But a frame with a past timecode must reference a frame already known, otherwise it's considered bad/void.