[FFmpeg-devel] [PATCH] H.264 timestamps in h264_parser - complete set

[Ivan Schreter]

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:
>>>>>         
>>>>>           
>>>>>> solution giving parser the control of frame duration seems cleaner to 
>>>>>> me.
>>>>>>             
>>>>>>             
>>>>> considering that your code depends on a 90khz clock which is not 
>>>>> guranteed
>>>>> and that repeat_pict must be fixed and unambigously specified for fields
>>>>> anyway i dont see any advantage of ignoring a existing field ans 
>>>>> introducing a
>>>>> new one
>>>>>
>>>>>         
>>>>>           
>>>> 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.

Alternatively, the timestamps in AVCodecParserContext must be 
represented as AVRational and recomputed in lafv. But this is probably 
more complex.

I'd go for first one. If lavf provides time_base information to lavc, it 
will compute timestamps, otherwise timestamp computation will not be 
done in lavc, only approximation in lavf.

> [...]
>   
>>> if its just for convergence_duration, then maybe a convergence_frames
>>> (different name and frame count instead of time) could be used.
>>>
>>>   
>>>       
>> OK, I've changed it, since it's not 100% sure the codec knows the time 
>> base. Patch attached.
>>     
>
> after rereading the text of the recovery SEI i think there is a more
> fundamental problem in h264 with convergence_*
> the way they specify it, is via frame_num, but frame_num does not
> increase for non reference pictures thus one not only can not infer
> the duration from it but not even the number of frames unless one
> knows which are reference frames (and one does not without scaning ahead).
> considering this, exporting the value makes no sense.
>
>   
:scratch, scratch:

It's very weird, true, but I have to agree with you. All consecutive 
B-frames effectively have the same frame_num and recovery_point is 
really defined via frame_num. The only thing we could do is to somehow 
infer something like GOP structure (pattern of reference and 
non-reference frames) and then use it to approximate.

Alternatively, instead of using "convergence_duration" we could define 
"convergence_flag" and then it's relatively easily possible. Simply, 
note down the frame number from SEI recovery point and when we reach it, 
we set the flag. Thus, application can test this flag after seek after 
decoding each picture, if it already reached the convergence point.

I'm getting more and more the feeling that the designers of H.264 
standard were quite detached from reality.

Regards,

Ivan