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

[Joel Cunningham]

> On Jan 12, 2017, at 10:08 AM, Andy Furniss <adf.lists at gmail.com> wrote:
> 
> 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.
> 

You’re correct that the sender's congestion control algorithm will gate how much is in-flight and while the sender is discovering the available network bandwidth, it won’t be sending a full window’s worth at a time.  I didn’t really bring this into the conversation (and kind of hand-waved it) because there isn’t any way that the receiver would know this information, thus we can’t use it to potentially reduce our “read-ahead/discard” size based on the receiver’s window size. 

If we wanted to be conservative about our read-ahead/discard size, taking into account a possible congestion control preventing a full window’s worth of data from being in-flight, we could potentially take the value from SO_RCVBUF and divide it by 1/2 or 1/4, but then we’d still have some possibility for discarded and re-sent data for larger seeks within the window once the window has fully opened up.  This kind of information isn’t available via socket APIs and typically isn’t needed by TCP applications (ffmpeg really has an unique use case by issuing HTTP range requests from current position till end, then aborting at some point during the HTTP response when needing to seek)

Joel