[FFmpeg-devel] [PATCH] H.264 timestamps in h264_parser - complete set
Ivan Schreter
schreter
Fri Feb 20 21:42:58 CET 2009
Michael Niedermayer wrote:
> On Fri, Feb 20, 2009 at 08:46:29PM +0100, Ivan Schreter wrote:
>
>> Michael Niedermayer wrote:
>>
>>> On Fri, Feb 20, 2009 at 06:52:30PM +0100, Ivan Schreter wrote:
>>>
>>>
>>>> Michael Niedermayer wrote:
>>>>
>>>>
>>>>> On Fri, Feb 20, 2009 at 04:00:34PM +0100, Ivan Schreter wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Michael Niedermayer wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Fri, Feb 20, 2009 at 03:30:16PM +0100, Ivan Schreter wrote:
>>>>>>>
>>>>>>>
>>>>>> That was also my question in another post - where do I get the clock in
>>>>>> lavc?
>>>>>>
>>>>>>
>>>>>>
>>>>> do you really need it?
>>>>>
>>>>>
>>>>>
>>>> Not for convergence, since we can express it via frame count. But for
>>>> pts/dts computation, definitely. For H.264 case, the stream must have 90kHz
>>>> clock according to H.264 standard, so it should be OK. But for other
>>>> codecs, I don't know.
>>>>
>>>> Alternative would be to scale pts/dts to some common unit (e.g.,
>>>> 1/1000000th second) and then rescale back.
>>>>
>>>>
>>> the container timebase in which pts/dts are specified is not
>>> guranteed to be 90khz, even if h264 says it is so, it just isnt in practice.
>>> things may work out because only mpeg-ps/ts ommit pts/dts "randomly" and
>>> mpeg-ps/ts have 90khz but .mp4/mov/nut/mkv do normally not use 90khz timebase
>>>
>>>
>>>
>> True, I downloaded some MOV AVCHD trailers and they don't work with
>> timestamping code correctly. Seem to use 1MHz clock, or so.
>>
>>
>>> also rounding is not ok
>>>
>>>
>>>
>> We'll need to communicate proper timebase for timestamping from lavf to
>> lavc in AVCodecParserContext, then, so it can compute timestamps correctly.
>>
>
> hmm i think the parser should export its dts/pts correction in
> AVCodecContext.time_base units (i think this is the correct one)
> and the code in lavf should then merge that into its dts/pts
>
>
The problem is, the timestamps are not integer multiples of time_base.
Not even the difference between them is an integer multiple - for
interlaced field picture movies, the timestamps of second field are
offset by 1/2 frame duration. So integer is not sufficient there.
Furthermore, current context already gets "real" pts/dts from lavf,
which only needs to be adjusted.
BTW, AVCodecContext.time_base is something like 1/25 (i.e., frame rate).
So I feel passing time base to lavc when initializing parser makes it
easier.
The timestamps in H.264 will not diverge, since we use container's
timestamp (wherever available) as reference.
So I was thinking about something like attached patch, which then
provides container_time_base to the parser. With this, I could get rid
of hard-coded 90kHz time base in H.264 timestamps calculation and it now
works for MOV as well.
OK so?
Regards,
Ivan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: avcodec_timebase.patch
Type: text/x-patch
Size: 3747 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090220/6d98adb9/attachment.bin>
More information about the ffmpeg-devel
mailing list