[Ffmpeg-cvslog] r8334 - trunk/libavformat/matroska.c

[Uoti Urpala]

On Tue, 2007-03-13 at 13:53 +0100, Michael Niedermayer wrote:
> the pts->dts code fails if EVERY of the following assumtations is true
>     codec is h.264
>     complex frame reordering is used (like b pyramid)
>     pts are available
>     dts are not available
>     dts are equal to sorted pts

The code also seems to use pkt->duration, which cannot be known
correctly based on pts without demuxing further. Does it always work
right with simpler frame reordering but VFR? Also with the Matroska
sample I tested even the incorrect dts calculation logic was not
triggered at all, but dts was always set equal to pts.

> until now these where impossible as every demuxer which could correctly
> handle h.264 would also provide dts at least AFAIK
> 
> solution is either
> A. the matroska deuxer sets dts
> B. the generic pts->dts sorting code gets improved (trivial) and
>    we somehow find the sorting buffer size from somewhere (not trivial)

Can the Matroska demuxer find the decode delay for sorting buffer or
otherwise calculate dts any easier than a generic implementation of B?
I'm not familiar enough with the Matroska spec to know all the fields
but at least I don't remember seeing mandatory fields which would allow
that.