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

Rich Felker dalias
Fri Mar 16 00:14:41 CET 2007

On Thu, Mar 15, 2007 at 11:38:05PM +0100, Michael Niedermayer wrote:
> > If it's going to do something potentially expensive then making it
> > optional might be worthwhile. 
> no its not expensive

I don't understand why it's not, but I'm glad nonetheless. :)

> > If you're going to decode the stream later
> > then it can be done more reliably at that time, when the decoder used
> > can tell how many frames it actually does buffer at the moment.
> so mplayers new timestamp generation code depends on decoding the stream?
> uhm, and you call ffmpegs dts generation code buggy?

Let's try to be civil, even though I too find Uoti annoying. :) I
agree with you of course, that requiring decoding to get correct
timestamps is broken since timestamps are needed for framecopy, etc.
However, if it's ever expensive to get them at demuxing time, it might
be an acceptable optimization to defer to decode-time as long as it
doesn't grossly increase the complexity.. If it's never expensive to
get them while demuxing, I think the deferring to decode is probably
just nasty complexity.


More information about the ffmpeg-cvslog mailing list