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

Ivan Schreter schreter
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?
>   
See above.

Regards,

Ivan




More information about the ffmpeg-devel mailing list