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;
+ }
buf_index += 3;
if (buf_index >= next_avc)
--
Jindřich Makovička
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
