Re: [FFmpeg-devel] Ticket 6375, Too many packets buffered for output stream
On Sun, 9 Jul 2017 13:38:10 +0200 Reimar Döffinger wrote: > On 09.07.2017, at 13:09, Michael Niedermayer 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. That's a libavfilter issue. In my own code, I do some sort of stream-with-no-data detection to work this around. The previous design had exactly the same problem, except it was within libavformat. ffmpeg.c used the codec parameters which libavformat "found" to initialize the filter chain. That means, it used libavformat's guess what the decoded AVFrames are going to look like. Now if a stream was "missing" data, libavformat just read more data ahead (sometimes making opening a stream extremely slow), or filled in the data with pure guesses. In some cases, libavformat would get parameters merely by opening a decoder, and e.g. using the sample format it set in the init function. Often enough, these parameters were incorrect too. Especially if other decoders than the default were used (typically external decoders, but also if you explicitly chose float vs. fixed point decoder - although it's possible that ffmpeg.c's messy option handling tried to force that as "probing" decoder in libavformat to aboid this problem). The best example for this is hardware decoding - libavformat will be completely wrong about the output format, and ffmpeg.c had to configure the filter chain again on the first decoded frame. The consequence was that it was really hard to build fully hardware filter chains. Also remember the awful hacks QSV used, which were needed not because QSV is bad, but because ffmpeg.c's filter setup was bad. In conclusion, what ffmpeg.c did before this change was certainly more broken than after this change. Also I don't know how often I explained this shit over and over again. Anyway, there is no real problem for ffmpeg.c. It's not like it behaved well with missing/sparse streams at any time. And in most cases, just enlarging the queue size will help. If you really care about the remaining cases, you could add code to set dummy filter params if no data is available. > You can do something like it if instead of failing when the buffering limit > is reached you then force stream processing of what is available, which is > kind of a compromise that usually works well but also makes things a bit > unpredictable. > 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... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Ticket 6375, Too many packets buffered for output stream
On Sun, 9 Jul 2017 13:09:28 +0200 Michael Niedermayer 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 > Request for more time at the time when the change was pushed: > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-March/207775.html > There's no bug, just a severe lack of understanding, and apparently an inability to read. There was more than enough time for testing. Before the patch got applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Ticket 6375, Too many packets buffered for output stream
On 09.07.2017, at 22:37, Hendrik Leppkes wrote: > > 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. Not sure if you're saying you want to avoid that? My point was just, assuming it is even possible to have one frame for every stream is not really correct, and it's not JUST bad files. But as an alternative suggestion, if you do not want obscure behaviour or hacks, maybe what really should happen is a better message? Something like "Stream A produced more data than could be buffered while waiting for first data on streams B, C and D. To fix this, please disable either stream A or streams B, C and D. Alternatively you can try to increase the buffer size (give option to increase)." Another workaround might actually be to specify the input file multiple times (in the cases where that is possible), selecting different stream subsets each time. Since disabling streams is of course not useful if the user really needs all of those (I don't think the ticket and current message has enough information to know if the problematic streams are actually useful). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Ticket 6375, Too many packets buffered for output stream
On Sun, Jul 9, 2017 at 1:38 PM, Reimar Döffinger wrote: > On 09.07.2017, at 13:09, Michael Niedermayer 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
Re: [FFmpeg-devel] Ticket 6375, Too many packets buffered for output stream
On 09.07.2017, at 13:09, Michael Niedermayer 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. You can do something like it if instead of failing when the buffering limit is reached you then force stream processing of what is available, which is kind of a compromise that usually works well but also makes things a bit unpredictable. 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... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Ticket 6375, Too many packets buffered for output stream
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 Request for more time at the time when the change was pushed: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-March/207775.html -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
