Hi, On Thu, Sep 27, 2012 at 12:44 PM, Jindřich Makovička <[email protected]> wrote: > On Thu, Sep 27, 2012 at 6:23 PM, Justin Ruggles > <[email protected]> wrote: >> On 09/27/2012 11:16 AM, Jindřich Makovička wrote: >>> Hi, >>> >>> I encountered $subj, with a (possibly broken, but I am not sure) h264 >>> stream, where the packet (or rather the rest of it) decoded in >>> try_decode_frame contained 3 bytes, and avcodec_decode_video consumed >>> no bytes, causing an infinite loop. >>> >>> More precisely, the last three bytes being processed were [54, 239, >>> 162] and h264.c:decode_frame always bailed out on the following >>> condition: >>> >>> if (!s->current_picture_ptr && h->nal_unit_type == NAL_END_SEQUENCE) { >>> >>> The attached patch adds a break if the decoder consumes no bytes and >>> produces no picture. >> >> Is there not a clean way to fix the h264 decoder? Not doing so means we >> would need to be clear to users that they will also have to check for >> this condition (and change api-example accordingly). > > In h264.c, it could be fixed by skipping junk bytes at the end of > buffer, when searching for a start code. > When there are only three bytes after NAL_END_SEQUENCE, the buffer > pointer gets stuck otherwise. > > --- a/libavcodec/h264.c > +++ b/libavcodec/h264.c > @@ -3694,8 +3694,10 @@ static int decode_nal_units(H264Context *h, > const uint8_t *buf, int buf_size) > buf[buf_index + 2] == 1) > break; > > - if (buf_index + 3 >= buf_size) > + if (buf_index + 3 >= buf_size) { > + buf_index = buf_size; > break; > + }
I'm fine with this. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
