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

Andy Furniss adf.lists at gmail.com
Thu Jan 12 19:22:50 EET 2017


Steinar H. Gunderson wrote:
> On Thu, Jan 12, 2017 at 04:59:33PM +0000, Andy Furniss wrote:
>> I've seen plenty of "legal" shrinks looking at tcpdumps - usually the
>> app is throttling it's read speed.
>
> You're not really allowed to shrink by more than you've received, though,
> are you? Typically the buffer going down is just that the app hasn't read all
> the data from the socket -- but that's a different case.

Correct - I was probably being over pedantic about one statement in the
context of buffer sizes.

> The point of the “no-shrink” rule is that once you've advertised a window to
> the sender, the sender should be allowed to send that much data with no ack,

Yes.

> without keeping a copy, and without worrying it might get lost. If you could
> shrink the window, that guarantee would disappear.

Not so sure about this bit = when the ack comes it may well inform that
a re-transmit is needed.



More information about the ffmpeg-devel mailing list