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

[Ganesh Ajjanagadde]

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.

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?

>
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
> questions about the command line tools should be sent to the ffmpeg-user ML.
> And questions about how to use libav* should be sent to the libav-user ML.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>