[FFmpeg-devel] [PATCH] avcodec/put_bits: fix off be one
Ronald S. Bultje
rsbultje at gmail.com
Sun Jan 24 18:27:07 CET 2016
Hi,
On Sun, Jan 24, 2016 at 12:24 PM, Ronald S. Bultje <rsbultje at gmail.com>
wrote:
> Hi,
>
> On Sun, Jan 24, 2016 at 12:13 PM, Paul B Mahol <onemda at gmail.com> wrote:
>
>> On 1/24/16, Ronald S. Bultje <rsbultje at gmail.com> wrote:
>> > Hi,
>> >
>> > On Sun, Jan 24, 2016 at 12:02 PM, Paul B Mahol <onemda at gmail.com>
>> wrote:
>> >
>> >> On 1/24/16, Paul B Mahol <onemda at gmail.com> wrote:
>> >> > On 1/24/16, Ronald S. Bultje <rsbultje at gmail.com> wrote:
>> >> >> Hi,
>> >> >>
>> >> >> On Sun, Jan 24, 2016 at 11:41 AM, Paul B Mahol <onemda at gmail.com>
>> >> wrote:
>> >> >>
>> >> >>> patch attached.
>> >> >>
>> >> >>
>> >> >> I think that's wrong. buf_end is buf_start+size, so if size=1, this
>> >> >> allows
>> >> >> writing up to and including buf_start[1], which overflows size=1.
>> >> >
>> >> > Assert happens otherwise when encoding flac.
>> >> >
>> >>
>> >> ffmpeg -i
>> http://granjow.net/uploads/kdenlive/samples/red-leaf-tips.avi
>> >> o.flac
>> >
>> >
>> > Is there a trac issue to track this? Do you have a backtrace?
>>
>> No, can you reproduce it?
>>
>
> * frame #0: 0x00007fff8d2ea286 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x00007fff8fd859f9 libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x00007fff895269b3 libsystem_c.dylib`abort + 129
> frame #3: 0x00000001003bc13c
> ffmpeg_g`flush_put_bits(s=0x0000000104800008) + 140 at put_bits.h:108
> frame #4: 0x00000001003bfc98
> ffmpeg_g`write_frame_footer(s=0x0000000104800000) + 184 at flacenc.c:1287
> frame #5: 0x00000001003bca35
> ffmpeg_g`write_frame(s=0x0000000104800000, avpkt=0x00007fff5fbfabf8) + 85
> at flacenc.c:1296
> frame #6: 0x00000001003bb788
> ffmpeg_g`flac_encode_frame(avctx=0x0000000102817000,
> avpkt=0x00007fff5fbfabf8, frame=0x0000000102302d20,
> got_packet_ptr=0x00007fff5fbfabf4) + 600 at flacenc.c:1404
> frame #7: 0x00000001007f2ed4
> ffmpeg_g`avcodec_encode_audio2(avctx=0x0000000102817000,
> avpkt=0x00007fff5fbfabf8, frame=0x0000000102302d20,
> got_packet_ptr=0x00007fff5fbfabf4) + 996 at utils.c:1769
> frame #8: 0x000000010001f10e ffmpeg_g`reap_filters [inlined]
> do_audio_out(s=<unavailable>, ost=<unavailable>) + 228 at ffmpeg.c:812
> frame #9: 0x000000010001f02a
> ffmpeg_g`reap_filters(flush=<unavailable>) + 1546 at ffmpeg.c:1364
> frame #10: 0x000000010001a2ff ffmpeg_g`transcode [inlined]
> transcode_step + 77 at ffmpeg.c:4084
> frame #11: 0x000000010001a2b2 ffmpeg_g`transcode + 18210 at
> ffmpeg.c:4128
> frame #12: 0x0000000100015548 ffmpeg_g`main(argc=<unavailable>,
> argv=<unavailable>) + 328 at ffmpeg.c:4319
>
> So it looks like it allocates one byte too little.
>
And a potential explanation for that is that encode_frame() does not
byte-align per channel or between header and channels.
Ronald
More information about the ffmpeg-devel
mailing list