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

Michael Niedermayer michaelni
Thu Mar 15 23:38:05 CET 2007


Hi

On Thu, Mar 15, 2007 at 11:01:28PM +0200, Uoti Urpala wrote:
> On Wed, 2007-03-14 at 22:25 +0100, Michael Niedermayer wrote:
> > our foobar codec has a picture buffer, each picture in it has a PTS
> > when we input a new frame we simply put it into the buffer with its pts
> > when we output a frame it has to be the one with the lowest PTS, why?
> > if we would output another one we couldnt output the one with the lowest 
> > PTS anymore as it would lay in the past
> 
> This is basically what MPlayer does with -correct-pts.
> 
> > now for this to work we need to know when a frame is input and when one
> > is output, input is trivial, output happens for each frame input as soon
> > as the buffer is full and for that we need to know the buffer size
> 
> Though MPlayer uses actual decoder behavior to detect when a frame is
> output, and only uses direct delay information (from decoder) to detect
> cases where a frame is dropped (input packet with no corresponding
> output).
> 
> > so what we need in practice is quite trivial but it will not work 100%,
> > nothing will short of a O(n) scan through the file ...
> > 
> > first av_find_stream_info() has to run the h.264 decoder over the first
> > few (10-20) frames to get the buffer size (AVCodecContext.has_b_frames)
> > this is easy it probably just requires us to prevent the loop in 
> > av_find_stream_info() from exiting too early for the h.264 case ...
> 
> If it's going to do something potentially expensive then making it
> optional might be worthwhile. 

no its not expensive


> 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?

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

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/20070315/b6ae7e8c/attachment.pgp>



More information about the ffmpeg-cvslog mailing list