[vlc-devel] [PATCH] Patch to fix bug #1532, and improve http seek times.

[Bill C. Riemers]

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;
>>              break;
>>     
>
> shoudln't this check p_sys->i_version? as it's 0 for http/1.0 and 1 for
> http/1.1.
>   
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
supported.
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.

Bill