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

Uoti Urpala uoti.urpala
Sun Mar 29 22:56:49 CEST 2009


On Sun, 2009-03-29 at 10:24 +0200, Ivan Schreter wrote:
> Uoti Urpala wrote:
> > MPlayer does not care about frame rate, it's perfectly fine if no two
> > intervals between frames in the video are the same and there is no sane
> > way to even define a "frame rate". What it cares about is packet
> > timestamps (the pts timestamp to be precise). And if there are two input
> > packets with set timestamps (not NOPTS_VALUE) for every output frame
> > from the decoder then things won't work well because the current code
> > does not know what input timestamp to associate with what decoder
> > output.
> >
> > To produce output that works with current MPlayer code libavformat would
> > need to either combine the packets so that one input packet corresponds
> > to one decoder output, or leave out "extra" timestamps that will not
> > correspond to anything output by the libavcodec decoder and use
> > AV_NOPTS_VALUE instead. Alternatively MPlayer can be changed to use a
> > different timing mode for such streams that have lots of timed packets
> > that do not correspond to video frames.
> >   
> Combining packets of one frame was also my first idea for solving the 
> problem of field-based videos. However, this solution is not correct. 
> There are also formats, which code more than one frame in one packet. So 
> it won't work.

What formats are those? I doubt there are many players which would play
that at all.

> However, to address your particular problem, consider the following:
> 
> 1) before calling avcodec_decode_video(), set reordered_opaque in codec 
> context to the PTS of the packet you want to decode.
> 2) after avcodec_decode_video() returns a frame, you can read PTS of 
> this frame in frame's reordered_opaque member.

This is one of the alternatives I considered for an alternative timing
mode (using reordered_opaque is somewhat ugly as the field is stupidly
coded to support int64_t only despite being an "opaque" value, but
that's not a major issue).

> To support the opposite case (more than one frame in one packet), some 
> more logic is necessary (e.g., first calling avcodec_decode_video() 
> without a packet and only if nothing is returned, feed it packets until 
> something will be returned). Also, I suppose it won't be possible to get 

Is there any decoder in libavcodec that actually produces multiple
frames from one packet? You're not confusing this with frame
doubling/tripling stuff which does not actually produce separate output
frames and can be mostly ignored by timestamp-based players?




More information about the ffmpeg-devel mailing list