[vlc-devel] [PATCH] Patch to fix bug #1532, and improve http seek times.
Bill C. Riemers
briemers at redhat.com
Fri Jun 13 18:31:05 CEST 2008
Ilkka Ollakka wrote:
> On to 12. kesäkuuta 2008 13:19:18, Bill C. Riemers wrote:
> Hi Bill,
> Seems to work ok for me (tested with mp4 files). Thou little detail:
>> case ACCESS_CAN_FASTSEEK:
>> pb_bool = (bool*)va_arg( args, bool* );
>> - *pb_bool = false;
>> + // http 1.1 should be just as fast as nfs...
>> + *pb_bool = p_sys->b_seekable;
> shoudln't this check p_sys->i_version? as it's 0 for http/1.0 and 1 for
Presumably that value is checked when setting p_sys->b_seekable.
Basically I am just making the code say
if this stream is seekable, it is also fast seekable. According to
Rémi Denis-Courmont, FASTSEEK should actually
mean non-blocking seek. So I just e-mailed another patch which changes
the http seek operation to be non-blocking.
> And shouldn't there be code in disconnect/close to send
> "Connection: close" to other end too?
Good question. I just checked RFC 2616 to be certain on this.
"Connection: close" is used be the server to indicate Keep-Alive is not
So the client side should never need to send "Connection: close".
I don't think the existing code correctly handles the case when the
server sends a "Connection: close" message, and my patch doesn't
either... At minimum we should set a flag upon receiving a connection
close, so we know to just use a new connection for reading the next
block, rather than only using the new connection after failing to use
the existing connection.
More information about the vlc-devel