Attached is a git format-patch file
0001-HTTP-improve-performance-by-reducing-forward-seeks.patch
Description: Binary data
> On Jan 26, 2017, at 6:52 PM, Michael Niedermayer wrote:
>
> On Thu, Jan 26, 2017 at 10:44:33AM -0600, Joel Cunningham wrote:
>> Michael,
>>
>> Thanks for the review an
On Thu, Jan 26, 2017 at 10:44:33AM -0600, Joel Cunningham wrote:
> Michael,
>
> Thanks for the review and testing! New patch included, see comments below
>
> >
> > this segfaults with many fuzzed files
> > backtrace looks like this:
> >
> > #0 0x7fffb368 in ?? ()
> > #1 0x005
Michael,
Thanks for the review and testing! New patch included, see comments below
>
> this segfaults with many fuzzed files
> backtrace looks like this:
>
> #0 0x7fffb368 in ?? ()
> #1 0x005f9280 in avio_seek (s=0x7fffb278, offset=31, whence=0)
> at libavformat/aviobuf.
On Fri, Jan 13, 2017 at 11:36:41AM -0600, Joel Cunningham wrote:
>
> > On Jan 12, 2017, at 10:59 AM, Joel Cunningham
> > wrote:
> >
> > Nicolas,
> >
> > I’ve found existing “read-ahead logic” in avio_seek to do what I’ve
> > implemented in http_stream_forward(). This is controlled by
> > SH
Ping! Anyone have a chance to review my latest patch which leverages the
read-ahead/discard logic in avio_seek?
Thanks,
Joel
> On Jan 13, 2017, at 11:36 AM, Joel Cunningham wrote:
>
>>
>> On Jan 12, 2017, at 10:59 AM, Joel Cunningham wrote:
>>
>> Nicolas,
>>
>> I’ve found existing “read-
> On Jan 12, 2017, at 10:59 AM, Joel Cunningham wrote:
>
> Nicolas,
>
> I’ve found existing “read-ahead logic” in avio_seek to do what I’ve
> implemented in http_stream_forward(). This is controlled by
> SHORT_SEEK_THRESHOLD, currently set to 4KB. I proto-typed increasing this to
> the 256
On Thu, Jan 12, 2017 at 10:59:56AM -0600, Joel Cunningham wrote:
> Nicolas,
>
> I’ve found existing “read-ahead logic” in avio_seek to do what I’ve
> implemented in http_stream_forward(). This is controlled by
> SHORT_SEEK_THRESHOLD, currently set to 4KB. I proto-typed increasing this to
> th
> On Jan 12, 2017, at 11:04 AM, Steinar H. Gunderson
> wrote:
>
> On Thu, Jan 12, 2017 at 04:59:33PM +, 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 yo
Steinar H. Gunderson wrote:
On Thu, Jan 12, 2017 at 04:59:33PM +, 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 bu
On Thu, Jan 12, 2017 at 04:59:33PM +, 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
Nicolas,
I’ve found existing “read-ahead logic” in avio_seek to do what I’ve implemented
in http_stream_forward(). This is controlled by SHORT_SEEK_THRESHOLD,
currently set to 4KB. I proto-typed increasing this to the 256KB (matches the
initial TCP window in my test setup) and saw the same nu
Joel Cunningham wrote:
According TCP RFCs, a receiver is not allowed to decrease the window,
Not sure that's true.
It's certainly possible to do it illegally, on a linux box tcp will log
a message something like heresy shrank window.
That IME is where some middle box is "interfearing".
I've
> On Jan 12, 2017, at 10:08 AM, Andy Furniss 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
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
> On Jan 12, 2017, at 6:53 AM, Nicolas George wrote:
>
> Le duodi 22 nivôse, an CCXXV, Joel Cunningham a écrit :
>> 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 conne
> On Jan 12, 2017, at 6:47 AM, Ronald S. Bultje wrote:
>
> Hi Joel,
>
> On Wed, Jan 11, 2017 at 6:01 PM, 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 s
Le duodi 22 nivôse, an CCXXV, Joel Cunningham a écrit :
> 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 becaus
Hi Joel,
On Wed, Jan 11, 2017 at 6:01 PM, 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 h
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 s
19 matches
Mail list logo
