| Message ID | 20171006201431.15839-1-cus@passwd.hu |
|---|---|
| State | Accepted |
| Commit | 41569bbc66d8971a1c5d369e5b335b3542f9cd26 |
| Headers | show |
On Fri, Oct 6, 2017 at 10:14 PM, Marton Balint <cus@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 <cus@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
On Fri, 6 Oct 2017, Hendrik Leppkes wrote: > On Fri, Oct 6, 2017 at 10:14 PM, Marton Balint <cus@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 <cus@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. Thanks, applied. Regards, Marton
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); ret = hw_device_setup_for_decode(ist); if (ret < 0) {
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 <cus@passwd.hu> --- fftools/ffmpeg.c | 3 +++ 1 file changed, 3 insertions(+)