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

Ganesh Ajjanagadde gajjanag at mit.edu
Mon Jul 13 18:14:07 CEST 2015


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.

>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list