On Sun, Jul 9, 2017 at 1:38 PM, Reimar Döffinger <reimar.doeffin...@gmx.de> wrote: > On 09.07.2017, at 13:09, Michael Niedermayer <mich...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
