On Fri, Oct 6, 2017 at 10:14 PM, Marton Balint <c...@passwd.hu> wrote: > Since af1761f7b5b1b72197dc40934953b775c2d951cc ffmpeg waits for a frame in > each > stream before writing the output header. If we are using threaded decoding for > attached pictures, we have to read till EOF to be able to finally flush the > decoder and output the decoded frame. This essentially makes ffmpeg buffer all > non-attached picture packets, which will cause a "Too many packets buffered > for > output stream" eventually. > > By forcing single threaded decoding, we get a frame from a single packet as > well and we can avoid the error. > > Fixes part of ticket #6375: > ffmpeg -i 46564100.mp3 -acodec libmp3lame -ab 128k -ac 2 out.mp3 > > Signed-off-by: Marton Balint <c...@passwd.hu> > --- > fftools/ffmpeg.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index 5be8788ea8..6eb7bf9d84 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c > @@ -2909,6 +2909,9 @@ static int init_input_stream(int ist_index, char > *error, int error_len) > > if (!av_dict_get(ist->decoder_opts, "threads", NULL, 0)) > av_dict_set(&ist->decoder_opts, "threads", "auto", 0); > + /* Attached pics are sparse, therefore we would not want to delay > their decoding till EOF. */ > + if (ist->st->disposition & AV_DISPOSITION_ATTACHED_PIC) > + av_dict_set(&ist->decoder_opts, "threads", "1", 0); >
LGTM. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
