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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
