[FFmpeg-devel] [PATCH] H.264: fix decoding of plain still images (broken since revision 14289)

Reinhard Nissl rnissl
Wed Jan 7 00:56:01 CET 2009


Michael Niedermayer schrieb:
> On Mon, Jan 05, 2009 at 11:35:03PM +0100, Reimar D?ffinger wrote:
>> On Mon, Jan 05, 2009 at 11:15:22PM +0100, Reinhard Nissl wrote:
>>> Some thoughts about the change: actually, it pulls just one
>>> picture from delayed_pics when a sequence end has been detected.
> So does your patch solve the problem at all?

In my use case (VDR, H.264 recording, showing the picture at the
cut mark position), the whole sequence consists only of a single
I picture and the sequence end code. So the patch solves my
problem, that this image was no longer shown.

> i mean with a stream that has a few delayed pics like one with b pyramid
> a following still image and a single sequence end code would not
> cause the still image to be returned

You're right. That's what I wanted to express with the above part
of my thoughts. In case were there are more delayed pictures
left, it will hopefully take the next one in display order --
haven't tested that yet. But I've already suggested a possible
solution for this issue below, to get all pictures up to the
still image.

> and actually, does it even work with normal IPB video + still image?

Haven't tested this yet. Just thought about such a scenario
(concatenating sequences) already below.

>>> One could go on and implement that for consecutive calls no bytes
>>> are consumed until all delayed_pics have been drained. This is
> this will likely not work

Sounds like returning 0 consumed bytes indicates an error.

>>> similar to calling decode with a zero sized buffer, but works in
>>> the case where for example two or more sequences have simply been
>>> catted together but separated by a sequence end code. Finally,
>>> idr() should be called too to initialize the decoder into a state
>>> where a next sequence which doesn't start with an idr can be
>>> properly decoded.
>> If this change is considered correct/acceptable, at least MPEG-2 should
>> be changed in the same way.
> mpeg2 currently does:
>     if (buf_size == 0 || (buf_size == 4 && AV_RB32(buf) == SEQ_END_CODE)) {
>         /* special case for last picture */
>         if (s2->low_delay==0 && s2->next_picture_ptr) {
>             *picture= *(AVFrame*)s2->next_picture_ptr;
>             s2->next_picture_ptr= NULL;
>             *data_size = sizeof(AVFrame);
>         }
>         return buf_size;

Well in MPEG-2 it's much easier as there is just a single delayed
picture: the future reference frame. I've added similar code some
years ago to xine-lib's libmpeg2 to retrieve the future reference
frame when a sequence end is detected. Regarding the above code
fragment, I've no idea what s2->low_delay==0 takes care of.

Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de

More information about the ffmpeg-devel mailing list