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

[Bill C. Riemers]

Rémi Denis-Courmont wrote:
> Le vendredi 13 juin 2008 19:31:05 Bill C. Riemers, vous avez écrit :
>   
>> 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.
>>     
>
> CAN_FASTSEEK means that seeking is fast/cheap. Of course, you can find 
> blocking operations are seomtimes faster than non-blocking ones, but 
> _typically_ not... Indeed, using my hard-drive, and even the hard-drive on 
> the other computer is my flat (over CIFS) is order of magnitude faster than 
> using an HTTP server outside. If a demux absolutely must seek, then CAN_SEEK 
> should be used. If seeking is just an optimization, then CAN_FASTSEEK should 
> be used.
>
> Even if the Seek callback of HTTP could be made non-blocking, it will still 
> add blocking operations. Worse yet, setting HTTP to CAN_FASTSEEK will break 
> the access filters. Basically, putting HTTP in CAN_FASTSEEK is a negation of 
> the CAN_FASTSEEK concept. Once you do that, one might as well identify 
> CAN_FASTSEEK with CAN_SEEK...
>   

Seek operations can always be fast.  All you do is defer any IO.   What
do you think happens when you do a NFS seek?   When the seek returns,
has the next data block been sent across the wire?  No it just told the
kernel the next place you want to read from.  From that point on the
kernel is busy negotiating with the NFS server to get you that data as
soon as possible.   Even when you request a seek off your hard drive,
the same thing happens.   The seek doesn't return when the hard drive
head has moved to the new data location, it returns when kernel has been
told were that location should be...

If we want the exact same behaviour  for  http, we simply need to
implement the same code logic in user space.   But that is really
optimizing read speeds...

What we define as fast seek, is really ambiguous.   But for the actual
seek call, I would consider anything non-blocking has fast.   The second
question you
can ask is what happens the response time on my next read?   For that I
maintain NFS and HTTP are going to respond with the same order of
magnitude of
time with properly written code, particularly for NFS over tcp-ip.  
Both still need to send the current block of data before the next block
of data can be sent.   And both need to send a request for the next
block of data.

Can I really say the new http code is fast as NFS?  Probably not. 
Particularly since I wrote the code to handle what I consider to be
typical use.   I just maintain speed is on the same order of
magnitude.   It is close enough that I don't notice any difference
playing my movies of NFS v.s. HTTP from the same server.  Could I make
it identical?  Probably, but I prefer to do things piecemeal.  
Implement a change that brings them to the same order of magnitude, and
then refine that as necessary.   If course given an ideal world I would
just use NFS.  But how many places offer public NFS?  Even within my own
firewall, I consider read only NFS a security risk.

Bill