[FFmpeg-devel] Ticket 6375, Too many packets buffered for output stream

Hendrik Leppkes h.leppkes at gmail.com
Sun Jul 9 23:37:35 EEST 2017

On Sun, Jul 9, 2017 at 1:38 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On 09.07.2017, at 13:09, Michael Niedermayer <michael at niedermayer.cc> wrote:
>> Hi all
>> It does appear this regression affects alot of people, judging from
>> the multiple different people in the ticket.
>> Also people ask me about this, for example baptiste yesterday hit it
>> too.
>> I belive multiple people where in favour of the change that caused
>> this regression. Does someone who was in favor of this change have
>> time to fix this ticket ?
>> I belive its important to fix this as it seems affecting many people.
>> Thanks
>> For reference:
>> Ticket: https://trac.ffmpeg.org/ticket/6375
>> Regressing Commit: https://github.com/FFmpeg/FFmpeg/commit/af1761f7b5b1b72197dc40934953b775c2d951cc
> Huh? I don't know if the commit message is accurate, but if it is the basic concept of this patch is utterly broken and can never work.
> There can be hours of video data before you actually get a frame on one of the "missing" streams (subtitles might be the most obvious case, but there are others), and buffering that much data simply is not possible.

The same limitation has always existed, it just moved to a different
place in a different form. For that matter, its only used for video
and audio, subtitles don't have any filtering or even well-defined
codec parameters.
There are just a few concepts colliding here: Many output formats
require information what the streams are before we actually start
writing streams, so we need to see a frame for those streams.

On top of that, FFmpeg (the application) is also quite inflexibel for
any re-configuration, and since it didn't actually ask the decoder it
was going to use for its output information, there could be
mis-matching data, which was usually fixed by making avformat behave
just the way ffmpeg.c wanted it to, instead of just reporting neutral
stream data.
Having ffmpeg.c decode a frame and take the actual output format from
the decoder has solved a large variety of issues. It may not be
perfect (yet), but within the limitations of crazy media files and
generally conflicting paradigms in various media formats, I think its
still far better then before.

Either extremely badly intereleaved streams or streams that just start
super late in the file have always been very problematic for decoding,
resulting in various hacks over the years to add "best-guess" default
values so at least something happens, even if the filtering has to
resample/rescale to match that guess in the end.

> Though since it seems to cause issues with audio files with cover image there's probably also bugs in the implementation itself, since handling those correctly is entirely possible...

I agree that the cover art thing is likely just a bug since those
cover art streams don't behave like normal streams. I'm a bit
short-pressed on time these days, but if noone else looks into it, I
can give it a try later this week.

- Hendrik

More information about the ffmpeg-devel mailing list