[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