[FFmpeg-devel] [PATCH] HTTP: optimize forward seek performance

[Andy Furniss]

Joel Cunningham wrote:
> Hi,
>
> I’ve been working on optimizing HTTP forward seek performance for ffmpeg and would like to contribute this patch into mainline ffmpeg.  Please see the below patch for an explanation of the issue and proposed fix.  I have provided evidence of the current performance issue and my sample MP4 so others can reproduce and observe the behavior.
>
> Files are located in Dropbox here: https://www.dropbox.com/sh/4q4ru8isdv22joj/AABU3XyXmgLMiEFqucf1LdZ3a?dl=0
>
> GRMT0003.MP4 - test video file
> mac-ffplay-baseline.pcapng - wireshark capture of ffplay (49abd) playing the above test file on MacOS 10.12.2 from a remote NGINX server
> mac-ffplay-optimize-patch.pcapng - same ffplay setup but with patch applied
> ffplay_output.log - console output of ffplay with patch (loglevel debug)
>
> I’m happy to discuss this issue further if the below description doesn’t fully communicate the issue.
>
> Thanks,
>
> Joel
>
>  From 89a3ed8aab9168313b4f7e83c00857f9b715ba4e Mon Sep 17 00:00:00 2001
> From: Joel Cunningham <joel.cunningham at me.com>
> Date: Wed, 11 Jan 2017 13:55:02 -0600
> Subject: [PATCH] HTTP: optimize forward seek performance
>
> This commit optimizes HTTP forward seeks by advancing the stream on
> the current connection when the seek amount is within the current
> TCP window rather than closing the connection and opening a new one.
> This improves performance because with TCP flow control, a window's
> worth of data is always either in the local socket buffer already or
> in-flight from the sender.

Not saying there is anything wrong with this patch but this statement
doesn't seem quite right.

I may be wrong, but IIRC what's in flight + buffer will also depend on
the state of the senders congestion control window.