[MPlayer-dev-eng] Accurate video pts handling

[Michael Niedermayer]

Hi

On Tue, May 09, 2006 at 10:19:06PM +0300, Uoti Urpala wrote:
[...]
> > whats the problem with using AVCodecContext.has_b_frames as the delay?
> 
> I think it doesn't always have the correct value for that use. It
> doesn't seem to be reset after seeks or errors which make lavc drop
> buffered frames.

could you elaborate?
if we seek, we flush the buffers so the number of frames in the decoder
becomes 0 (you also could flush the pts buffer here), and at the time 
when we output the next frame it should be AVCodecContext.has_b_frames 
again, this seems correct?

if theres an error lavc might try to recover part of the frame and output
that or drop it, ffmpeg should probably provide more status info about 
what happened ...


> 
> > alternatively if dts are available they can be used if not pts can be
> > feeded into the decoder and reordered in it
> 
> dts values only work if you make assumptions about decoder behavior
> (whether it does unnecessary buffering to nominal decode delay or not),

if a decoder does unnecessary buffering then its buggy (the specs like mpeg*
is very explicit on these things IIRC)


[...]

> > either way i disslike your changes to vd_ffmpeg.c, they are messy
> 
> I agree they're messy. As I said, the patch was not meant to be finished
> code. It could be cleaned up somewhat, but I think the general approach
> is the only one that works with current libavcodec. Changing libavcodec
> instead would enable a cleaner solution. Just doing the same buffer
> counting on the libavcodec side would make it much less messy, though it
> would require numerically more code changes.

theres also something entirely different ... what about remuxing without
a decoder (-vcodec copy / -acodec copy)? this also needs correct timestamps

[...]
-- 
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is