On 2 August 2017 at 00:35, Rodger Combs <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?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
