[FFmpeg-devel] Remaining problems in H.264 handling
Sun Mar 29 23:11:13 CEST 2009
Uoti Urpala wrote:
> On Sun, 2009-03-29 at 10:24 +0200, Ivan Schreter wrote:
>> 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.
AFAIK H.263 has so-called PB-frames, where one P and one B frame are
coded in one packet. But I'm no expert in this area. I remember seeing a
long thread on ML about a month ago regarding support of PB frames.
>> 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).
I admit, it is a bit ugly, or better to say, the name is not quite
intuitive. But 64-bit opaque value can be also used to store a pointer
to any structure, so if you need to associate more info, store a pointer
to struct there. Just make sure the struct is also correctly freed in
case of several packets per frame...
>> 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