[FFmpeg-devel] [PATCH] ffmpeg_opt: discard packets correctly

[Michael Niedermayer]

On Mon, Jul 13, 2015 at 09:32:06AM -0400, Ganesh Ajjanagadde wrote:
> On Mon, Jul 13, 2015 at 7:11 AM, Michael Niedermayer
> <michael at 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 <gajjanagadde at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150713/cc3ec9f6/attachment.sig>