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

[Hendrik Leppkes]

On Mon, Jul 13, 2015 at 6:14 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
> On Mon, Jul 13, 2015 at 12:02 PM, Michael Niedermayer
> <michael at 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
>>> <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
>
> 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