[FFmpeg-devel] Patch: CrystalHD decoder support

Michael Niedermayer michaelni
Fri Jan 7 14:48:27 CET 2011

On Fri, Dec 31, 2010 at 02:45:21PM -0700, Philip Langdale wrote:
> 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

well, no, mplayers concept of reordering timestamps independant of the decoder
is flawed.

the decoder has to reorder them with the data ...
its simple a packet goes in with pts and that gets decoded to a bitmap and
the pts still should be associated with that and both are output

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110107/23fffce4/attachment.pgp>

More information about the ffmpeg-devel mailing list