[FFmpeg-devel] [PATCH] CrystalHD decoder support v2

[Vladimir Pantelic]

Vladimir Pantelic wrote:
> On 12/29/2010 06:51 PM, Philip Langdale wrote:

>>  I dug through the library code and for the 70015, it really looks like
>>  they scale
>>  down and up by 10000 (not 100000 as I used), so I don't have a choice
>>  but to try
>>  and defend against it. it seems that the timebase the hardware uses
>>  changed between
>>  the 70012 (100ns units) and the 70015 (1ms units) so they kept the
>>  library interface
>>  at 100ns units and then convert back and forth. There isn't any other
>>  place I can
>>  carry the value around with. :-/
>
> yes, but still you have to try to keep the value intact. And you
> cannot rely on reordered_opaque to be a timestamp, so I think your
> 1st approach to use pkt->pts was better. If you cannot attach
> arbitrary data to a frame, you might keep a list/queue where you
> keep track about which opaque value belongs to which timestamp.

so, you pass a timestamp here:

	ret = DtsProcInput(dev, avpkt->data, len, pts, 0);

and you get it back (hopefully unchanged) from here:

  	output->PicInfo.timeStamp

right?

so, you have a way to identify a returned frame from this value
which means you have a way to return the value of reordered_opaque
as well. And as said, you cannot assume that reordered_opaque is
a timestamp, it could be anything:

     /**\
      * reordered opaque 64bit (generally an integer or a double precision float\
      * PTS but can be anything). \
	...


btw, does the decoder actually use the "pts" value you pass? does it break decoding
if you pass e.g. 1, 2, 3, 4, 5 etc?