On 4/13/18, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Wed, Apr 11, 2018 at 1:40 PM, Hendrik Leppkes <h.lepp...@gmail.com>
> wrote:
>> If a frame starts very close to a packet boundary, the start code may
>> already have been added to the parsing buffer, indicated by a small
>> negative value of "i", while the header is still being tracked in the
>> "state" variable.
>>
>> Reduce the remaining size accordingly, otherwise trying to find the next
>> frame could skip over the frame header and lump two frames together as
>> one.
>> ---
>> libavcodec/aac_ac3_parser.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
>> index 019074b0dd..7f20626285 100644
>> --- a/libavcodec/aac_ac3_parser.c
>> +++ b/libavcodec/aac_ac3_parser.c
>> @@ -60,6 +60,8 @@ get_next:
>> s->remaining_size += i;
>> goto get_next;
>> }
>> + else if (i < 0)
>> + s->remaining_size += i;
>> }
>> }
>> }
>> --
>> 2.16.1.windows.4
>>
>
> Ping.
> Note that this is somewhat of a regression in AC3 parsing since the
> recent AC3+EAC3 combined stream support (the bug existed before, but
> that change exposed it).
Please add { } brackets around new code.
Patch LGTM otherwise.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
