[Ffmpeg-cvslog] r8334 - trunk/libavformat/matroska.c
Tue Mar 13 13:53:48 CET 2007
On Tue, Mar 13, 2007 at 01:02:57PM +0100, Baptiste Coudurier wrote:
> 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
Size: 189 bytes
Desc: not available
More information about the ffmpeg-cvslog