[vlc-devel] Patch for Trac Ticket #2533 -- MMS startdelay

[Keary Griffin]

Just to make it clear, this patch is intended to fix a long delay, in 
the neighborhood of two minutes.

Looking at those two streams and I don't think this patch will have any 
effect...  It is meant to fix a stream that looks like this (there is 
extra debugging here to print the http header that I added that is not 
in the regular VLC):

[0x229cad8] main access debug: net: connecting to xxx.xxx.xxx.xxx port 2443
[0x229cad8] main access debug: connection succeeded (socket = 22)
[0x229cad8] access_mms access debug: HTTP reply 'HTTP/1.0 200 OK'
[0x229cad8] access_mms access debug: Server: Rex/11.0.5721.5265
[0x229cad8] access_mms access debug: Cache-Control: no-cache
[0x229cad8] access_mms access debug: Pragma: no-cache
[0x229cad8] access_mms access debug: Pragma: client-id=1384330131
[0x229cad8] access_mms access debug: Pragma: features="broadcast,playlist"
[0x229cad8] access_mms access debug: stream type = broadcast
[0x229cad8] access_mms access debug: Content-Type: 
application/vnd.ms.wms-hdr.asfv1
[0x229cad8] access_mms access debug: Content-Length: 5015
[0x229cad8] access_mms access debug: content-length = 5015
[0x229cad8] access_mms access debug: Connection: Keep-Alive
[0x229cad8] access_mms access debug: Keep-Alive header found
[0x229cad8] access_mms access debug: complete header size=5003
[0x229cad8] access_mms access debug: packet count=4294967295 packet 
size=1444

Notice that Connection: Keep-Alive header being sent by the server.  
Without the patch the current VLC git version would delay for a couple 
of minutes and then timeout, continue and play the video.  With the 
patch (the above has the patch) the code doesn't wait for the timeout, 
it just waits for "content-length" data and then continues.  This 
eliminates the 2 minute delay.

The reason I think it fixes bug 2533 is because in this thread, which 
links to that bug:
http://forum.videolan.org/viewtopic.php?f=14&t=45844

The following IP sniffing is posted:
VLC -> WMSE GET / HTTP/1.0..Host: WMSencoder..
VLC -> WMSE Accept: */*..User-Agent: NSPlayer/7.10.0.3059..Pragma: 
no-cache,rate=1.000000,stream-time=0,stream-offset=0:0,request-context=1,max-duration=0..Pragma: 
xClientGUID={babac001-9fb8-f91c-daf83df5f86fee0a}..Connection: Close....
WMSE -> VLC HTTP/1.0 200 OK..Server: Rex/11.0.5721.5145..Cache-Control: 
no-cache..Pragma: no-cache..Pragma: client-id=2342587066..Pragma: 
features="broadcast,playlist"..Content-Type: 
application/vnd.ms.wms-hdr.asfv1..Content-Length: 5428..Connection: 
Keep-Alive....

and I noticed the same content-length and Keep-Alive headers being sent 
by the server right before the user mentioned before a 2 minute delay 
(which makes sense).

Unfortunately the stream mentioned by that post is on a private network 
(192.168...)  I wish I could post a link to the stream I was testing 
with (the reason I wrote the patch) but it is at a client's site.   From 
the looks of the headers it is running Windows Media Encoder 
Rex/11.0.5721.5265

So I guess the bottom line is I know this patch fixes my problem, and I 
would hazard a guess it would fix the problem mentioned in the post 
referenced above, but I don't know whether it fixes all of the issues 
mentioned in the bug & thread.  Most of the links in that thread seem to 
work for me with or without the patch.  It's possible that VLC already 
fixed something else, or that the servers they are running on have been 
updated, but that is just wild speculation.

Keary
Kaarlo Räihä wrote:
> I tested under Win32 with VLC 1.1.0-git-20100326-0002 using 
> URLs mms://wm9.streaming.telstra.com/UCS-wh_fbi0live1 
> <http://wm9.streaming.telstra.com/UCS-wh_fbi0live1> 
> and http://www.radio88.nu/listen.asx and delay is almost gone. 
> Unfortunately I can't test your patch since my own nightly build seems 
> to crash if I try to open those URLs in it (I have no clue why).
>
> 2010/3/26 Keary Griffin <keary.griffin at unwiredappeal.com 
> <mailto:keary.griffin at unwiredappeal.com>>
>
>     I'm attaching a patch that I believe takes care of the issue in
>     Ticket #2533 "MMS stream opening hangs for few minutes".  (This is
>     a cleaned up version of the patch I mentioned in a previous thread)
>
>     The problem appears to be that even though VLC sends a request
>     using "GET / HTTP/1.0" and does not request a keep-alive
>     connection, the servers in question respond with a keep-alive
>     connection.  I believe this is actually a server problem but it is
>     pretty common.  This causes VLC to wait for a timeout before
>     proceeding.
>
>     This patch makes VLC look for a "Connection: Keep-Alive" and
>     Content-Length header, and if found only reads that much data from
>     the connection.
>
>     Keary
>
>     _______________________________________________
>     vlc-devel mailing list
>     To unsubscribe or modify your subscription options:
>     http://mailman.videolan.org/listinfo/vlc-devel
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20100327/527da3b6/attachment.html>