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

[Kaarlo Räihä]

OK, that explains it. I assumed there was just one issue. If anyone has
non-working URL, please share :)

2010/3/27 Keary Griffin <keary.griffin at unwiredappeal.com>

>  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 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>
>
>> 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
>
>
> _______________________________________________
> 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/20100328/3ca6dd51/attachment.html>