On Mon, Jul 13, 2015 at 6:14 PM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: > On Mon, Jul 13, 2015 at 12:02 PM, Michael Niedermayer > <mich...@niedermayer.cc> wrote: >> On Mon, Jul 13, 2015 at 09:32:06AM -0400, Ganesh Ajjanagadde wrote: >>> On Mon, Jul 13, 2015 at 7:11 AM, Michael Niedermayer >>> <mich...@niedermayer.cc> wrote: >>> > On Mon, Jul 13, 2015 at 02:44:00AM -0400, Ganesh Ajjanagadde wrote: >>> >> libav commit 13f6917c merged in 574dcb5b results in >>> >> unnecessary seeks due to discarded packets; >>> >> especially problematic over a network. >>> >> >>> >> Fixes Ticket4126 >>> >> >>> >> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> >>> >> --- >>> >> ffmpeg_opt.c | 10 +++++++--- >>> >> 1 file changed, 7 insertions(+), 3 deletions(-) >>> > >>> > i dont think that not marking streams for discarding can be correct >>> > to fix a speed regression. >>> > >>> > Reading should not become significantly slower in a >>> > real world (non constructed) case when a stream is marked as discard >>> > >>> > See short_seek_threshold, maybe it can be adjusted for http or >>> > network protocols or maybe ff_configure_buffers_for_index() could >>> > adjust things to avoid seeks for discarded streams >>> > >>> > A fix purely in ffmpeg_opt also has the disadvanatge that it would >>> > not help any other applications which use libavformat with discarded >>> > streams >>> >>> Before I dive deeper into this, I have a few comments and questions: >>> 1. I tested against not just the example in the ticket, >>> but also against random test files obtained at >>> http://download.wavetlan.com/SVV/Media/HTTP/http-mp4.htm; >>> I don't know whether these are close enough to real world examples. >>> It therefore seems like reading (without above patch) does become >>> significantly slower for at least mp4 files delivered over http. >>> Basically, there are a huge number of redundant partial chunk http requests, >>> due to seeks that don't fall within existing buffers as they have been >>> discarded. >> >> yes >> >> >>> >>> 2. I used the above simple fix as libav commit 13f6917c >>> did not offer any clear reason as to what was being fixed >>> (on the mailing list archive): >>> https://lists.libav.org/pipermail/libav-devel/2012-February/022525.html >>> https://lists.libav.org/pipermail/libav-devel/2012-February/022527.html >>> beyond "useful for debugging" and "not return packets for streams we >>> are not interested in". >>> Can someone give me a clearer reason or concrete use case >>> where the above libav commit did something beneficial? >> >> in a network protocol where streams can be disabled so they are not >> transmitted enabling all streams would be a problem due to possibly >> significantly increased bandwidth usage. >> i do not know if the commit actually did help this case but >> simply not using a feature is not fixing a bug in that feature. >> even if we revert that commit, there still would be a problem >> with http and disabled streams > > The irony is that the commit on first glance would decrease network usage > due to the disabled stream. > However, in reality, the only observed effect right now (at least for me) > is an increased network usage (precisely responsible for the slowdown). > This requires further investigation as you pointed out. >
Often this can be a case where avformat starts to seek the stream instead of just reading it - while that uses less data overall, the latency from the seek will sometimes add more time than simply reading the unwanted data. Over HTTP for example, a continous stream is usually always going to be much faster than byte-seeking the file for every input packet. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
