[FFmpeg-devel] Remaining problems in H.264 handling
Sun Mar 29 23:26:59 CEST 2009
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
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
220.127.116.11, 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.
More information about the ffmpeg-devel