aboutsummaryrefslogtreecommitdiffstats
path: root/libavfilter/vf_thumbnail.c
diff options
context:
space:
mode:
authorMarton Balint <cus@passwd.hu>2017-10-06 21:49:09 +0200
committerMarton Balint <cus@passwd.hu>2017-10-08 22:32:13 +0200
commit41569bbc66d8971a1c5d369e5b335b3542f9cd26 (patch)
tree914a2693a7156af22f0f64fc853eacf20d76e2d7 /libavfilter/vf_thumbnail.c
parent41d6d627024393c142cf7cd93eff1d5a049105f5 (diff)
downloadffmpeg-41569bbc66d8971a1c5d369e5b335b3542f9cd26.tar.gz
ffmpeg: always use single threaded decoding for attached pictures
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 Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com> Signed-off-by: Marton Balint <cus@passwd.hu>
Diffstat (limited to 'libavfilter/vf_thumbnail.c')
0 files changed, 0 insertions, 0 deletions