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.cunning...@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
