[vlc-devel] [PATCH] Correctly respond to a Connection Close message.

[Bill C. Riemers]

Rémi Denis-Courmont wrote:
> This is not a bug fix. The bug is in the AVI demux. Lets call a cat a cat, 
> this is a regression in the AVI demux - it had been working for several years 
> without seeking, and it broke sometime during the 0.9.0 development.
>
>   
No.  The 0.8.6 series is equally broken.

> You are improving the HTTP access. This is probably a good idea, but it will 
> probably never fix the AVI problem. We have other access plugins, such as 
> FTP, that will continue to exhibit the problem.
>   

> Of course, we can change the AVI demux to use CAN_SEEK instead of 
> CAN_FASTSEEK. If nobody fixes the AVI demux soon enough, we may end up doing 
> this *work-around* for 0.9.0.
>   

Lets be clear.   There are two bugs and two enhancements:

Bug 1:
AVI streams which can not be FASTSEEK'ed are reported as corrupt.

Bug 2:
Http streams close when the requested seek position is past the EOF, but
file streams do not.   I'm not sure which is the bug.  Should file
streams close when we seek to far, or should http streams be left
open?   The current DEMUX code assumes the stream will be left open,
which is why I'm inclined to fix the http stream, not to break things
further by changing the file stream.

Enhancement 1:
Allow seeking in avi http streams.  Http streams are fast enough to
allow seeking in AVI's.   So either the DEMUX for avi's should use
CAN_SEEK instead of CAN_FASTSEEK, or http streams are fast enough to be
considered FASTSEEK.   It seems to me this used to work in much older
versions of vlc, but perhaps my memory is playing tricks on me.

Enhancement 2:
Seeking times for http streams can be greatly improved.

> But it should be understandable that I would rather not have the _same_ patch 
> doing both a work-around to the AVI demux, and some loosely-related 
> improvements to the HTTP access, right? If you don't feel like doing it 
> yourself because you don't like/know git, that's fine, if you do tell.
>   
The reason they are correlated together, is if you change AVI to
CAN_SEEK, but do not also modify http.c, then the avi demux will simply
seek past the end of the file, the stream will be closed, and the video
will not play.

I would be happy to commit the patches to the archive, but to do that I
would need write access.

> By the way, b_persist should probably default to false on HTTP/1.0, no?
>   
Actually no.  So long as we send "Connection: Keep-Alive" even HTTP/1.0
connections are persistent.   Not that it does us much good without
being able to request a particular byte range.

Bill