On Fri, Apr 13, 2018 at 11:54 AM, Paul B Mahol <one...@gmail.com> wrote: > 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. >
Applied with that changed. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel