[FFmpeg-devel] Remaining problems in H.264 handling

[Ivan Schreter]

Michael Niedermayer wrote:
> On Sat, Mar 28, 2009 at 11:22:06PM +0100, Ivan Schreter wrote:
>   
>> Michael Niedermayer wrote:
>>     
>>> On Fri, Mar 27, 2009 at 07:56:59PM +0100, Ivan Schreter wrote:
>>>   [...]
>>>       
> [...]
>   
>>> 2. there is no frame rate field, and i repeat like i did many times in the
>>>    past that people CANNOT hijack a timebase or the r_frame_rate field
>>>    and set them to the frame rate.
>>>    if you want a frame rate field that has to be added as a new field.
>>>
>>>   
>>>       
>> I don't have sources on this computer and I don't remember exactly, so I'm 
>> not going to write proper member names here.
>>
>> However, AFAIK we have following: time base of the stream (90kHz for 
>> MPEG-TS), which is rather uninteresting (it's just scaling constant), 
>> timestamp rate (50Hz) and actual video full frame rate (25fps).
>>     
>
> you make random assumptions, there is nothing in the spec that requires
> the timestamp rate as you call it to be that it can be 90khz or anything
> else.
>   
Sorry, I was not precise again. I meant 50Hz and 25fps as examples for 
further explanations. 90kHz is only for MPEG-TS (H.222.0 explicitely 
states that DTS/PTS timestamps are 90kHz, see H.222.0, 2.14.1 and 
2.4.3.6, though the actual AVC timestamps may have different resolution 
-- I believe, there might be some issue still present there in MPEG-TS, 
BTW), other formats can use other time base, of course.

>> The problem: video full frame rate will be currently determined by 
>> "unreliable" handling, where timestamps of *packets* are considered, 
>> instead of *frames*, packet timestamps being expressed in 50Hz. Thus, video 
>> consisting of field pictures (2 field pictures per video frame) will get 
>> frame rate 50fps instead of correct 25fps. Video consisting of frame 
>> pictures will get correct frame rate 25fps. Video consisting of "frame 
>> doubling" pictures will get frame rate 12.5fps.
>>     
>
> i dont understand what you are trying to say, r_frame_rate is a guessed
> value to begin with and it is not the frame rate but a guess at a simple
> timebase in which all timestamps can be represented this is documented
> clearly in avcodec.h.
>
>   
I'm not talking about r_frame_rate member, but about actual frame rate 
(e.g., for display in a player or for transcoding, etc.).

According to your other post, it looks like we should introduce an 
explicit frame rate field parallel to the current r_frame_rate (which is 
then IMHO misnamed, since it's not frame rate). But I cannot look at the 
details now, since I don't have access to the sources right now.

Regards,

Ivan