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

[Michael Niedermayer]

Hi

On Tue, Mar 13, 2007 at 01:02:57PM +0100, Baptiste Coudurier wrote:
> Hi
> 
> Uoti Urpala wrote:
> > On Mon, 2007-03-12 at 23:19 +0100, Aurelien Jacobs wrote:
> >> On Mon, 12 Mar 2007 22:03:56 +0000
> >> M?ns Rullg?rd <mans at mansr.com> wrote:
> >>> I don't see any jerkiness playing those with ffplay from svn r8317 or
> >>> with TCVP using its matroska demuxer.
> >> Try with ffplay r8333.
> >> r8317 was broken (pts was meaningless so ffplay generated the pts itself,
> >> which lead to properly ordered pts and smooth playback, but AV desync
> >> when both streams didn't start at the same pts).
> > 
> > I took a quick look at the logic libavformat uses to calculate dts based
> > on pts and it seems generally broken. 
> 
> Could you please elaborate ?

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

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)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20070313/d549f39e/attachment.pgp>