[FFmpeg-devel] Remaining problems in H.264 handling
Sun Mar 29 01:03:33 CET 2009
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
> 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.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is not what we do, but why we do it that matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel