[FFmpeg-devel] Patch: CrystalHD decoder support

[Philip Langdale]

 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
> displayed
>    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 
> are
> 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 
> the
> decoder is laging behind a theoretical reference decoder. (thus it 
> can also
> change)
>
> I dont know if this will fix the initial many second sync issue you 
> describe
> or if this is a unrelated issue

 Ok - so it sounds like what you want is basically mplayer's 
 buffered_pts concept
 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 
 patch).

 mplayer just uses that and doesn't interact with ffmpeg's dts or 
 reordered_opaque
 mechanisms at all; rather it independently reorders the pts values to 
 be monotonic
 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 
 - no
 surprise I guess).

 Thanks,

 --phil