[FFmpeg-devel] [PATCH] H.264 timestamps in h264_parser - complete set
Thu Feb 19 23:28:48 CET 2009
On Thu, Feb 19, 2009 at 10:58:41PM +0100, Ivan Schreter wrote:
> Michael Niedermayer wrote:
>> On Thu, Feb 19, 2009 at 06:23:41PM +0100, Ivan Schreter wrote:
>>> Michael Niedermayer wrote:
>>>> i would prefer if convergence_duration in AVCodecParserContext where
>>>> defined the same way as in AVPacket, its a source of confusion otherwise
>>> I copied the docs from AVPacket changing timestamp to frame count.
>>> Namely, it can't be quite the same, the codec doesn't necessarily have to
>>> know the duration of one frame. So it can't be timestamp, only frame
>> there is no reason why a codec couldnt store the timestamp and not the
>> frame count
> Ah, I missed this one when replying to your mail.
> Attached is a modified patch, which makes the codec responsible for setting
> convergence_duration to proper value in stream time units, so it should be
> OK now.
> However, I'm not 100% sure, if it will work this way. For H.264, we have
> 90kHz clock, at least for MPEG-TS. But how about other formats? Are they
> forced to use 90kHz as well? If not, how does the codec know what time base
> the stream has? It may not depend on AVStream, right? Otherwise, we'd have
> a circular dependency between lavf and lavc.
the parser also can set timetamps, they as well are in a container based
besides we can change it if it doesnt work out, the main thing i care about
is that we dont have 2 convergence_duration fields with different meaning
and patch ok
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel