> On Nov 21, 2017, at 19:03, Rostislav Pehlivanov <atomnu...@gmail.com> wrote: > > On 2 August 2017 at 00:35, Rodger Combs <rodger.co...@gmail.com > <mailto:rodger.co...@gmail.com>> wrote: > >> >>> On Aug 1, 2017, at 18:25, James Almer <jamr...@gmail.com> wrote: >>> >>> On 8/1/2017 3:33 AM, Rodger Combs wrote: >>>> --- >>>> libavformat/flacenc.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/libavformat/flacenc.c b/libavformat/flacenc.c >>>> index 9768b6a..1906aee 100644 >>>> --- a/libavformat/flacenc.c >>>> +++ b/libavformat/flacenc.c >>>> @@ -322,7 +322,7 @@ static int flac_write_trailer(struct >> AVFormatContext *s) >>>> if (!c->write_header || !streaminfo) >>>> return 0; >>>> >>>> - if (pb->seekable & AVIO_SEEKABLE_NORMAL) { >>>> + if (pb->seekable & AVIO_SEEKABLE_NORMAL && (c->streaminfo || >> s->streams[0]->codecpar->extradata_size == FLAC_STREAMINFO_SIZE)) { >>> >>> In what situation would stream extradata or c->streaminfo be smaller >>> than FLAC_STREAMINFO_SIZE? Nothing changes par->extradata anywhere, and >>> c->streaminfo is always allocated with FLAC_STREAMINFO_SIZE bytes of >> memory. >>> I have the feeling i already asked this before, but not sure if you >>> answered it. Apologies if you did. >> >> It shouldn't happen in normal cases, but you could imagine a case with >> remuxing a corrupted input file. >> > > Shouldn't the demuxer handle this?
Even in e.g. MKV? > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel> _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
