[FFmpeg-devel] Patch: CrystalHD decoder support
Fri Dec 31 22:45:21 CET 2010
On Fri, 31 Dec 2010 03:53:55 +0100, Michael Niedermayer
<michaelni at gmx.at> wrote:
> there are 2 timestamps
> 1. pts, they represent the time at which the binary packet should be
> once it is decodec (this goes through reordered_opaque)
> 2. dts, they represent the time at which the output that happens to
> come out
> of the decoder should be displayed.
> With your code dts based timing support is lost. This is bad when pts
> unavailable or where they are incorrect due to buggy encoder.
> basically whats needed is a fifo into which the dts are feeded
> similar to
> reordered_opaque. The size of this fifo would be the number of frames
> decoder is laging behind a theoretical reference decoder. (thus it
> can also
> I dont know if this will fix the initial many second sync issue you
> or if this is a unrelated issue
Ok - so it sounds like what you want is basically mplayer's
but with a dynamically allocated buffer (currently mplayer's is 20
which is too
tight for crystalhd in practice so I've had to bump it in my mplayer
mplayer just uses that and doesn't interact with ffmpeg's dts or
mechanisms at all; rather it independently reorders the pts values to
increasing and assumes the decoder will reorder frames to match.
I've had good results with my patch and mplayer in most cases, but
there are still
some I have to resolve (mostly interlaced content in mpeg-ts containers
surprise I guess).
More information about the ffmpeg-devel