[streaming] Trying to understand why RTSP playing of video with a Windows Media Server source fails to fin d the end-of-stream properly

From what I was able to find on the Internet (working with Linux VLC as server 
and client), the basic problem is that RTSP 1 has no standard end-of-stream 
mechanism at all, which seems kind of a glaring omission to me.  There are a 
couple of mechanisms in various not-totally-standard implementations, and 
some of those are being debated for RTSP 2.0.  I did not find anything 
implemented in VLC but I looked mainly in 0.8.6.

Hacking the ANNOUNCE message (meant for announcing available streams) seems to 
be in the lead as an RTSP end-of-stream message now.  It's something I may 
need to implement in the next weeks or months, if I do I will submit a patch.  
However that probably will not help you with WMS.  Hacking the SET_PARAMETER 
as end-of-stream, as in your capture, is probably unique to Microsoft.

Regards,
Charles Hordis

On Thursday 15 May 2008 08:06:03 pm [email protected] wrote:
> Send streaming mailing list submissions to
> 	[email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mailman.videolan.org/listinfo/streaming
> or, via email, send a message with subject or body 'help' to
> 	[email protected]
>
> You can reach the person managing the list at
> 	[email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of streaming digest..."
>
>
> Today's Topics:
>
>    1. Trying to understand why RTSP playing of video with a	Windows
>       Media Server source fails to find the end-of-stream	properly...
>       (Lewis G. Pringle, Jr.)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 15 May 2008 20:06:49 -0400
> From: "Lewis G. Pringle, Jr." <[email protected]>
> Subject: [streaming] Trying to understand why RTSP playing of video
> 	with a	Windows Media Server source fails to find the end-of-stream
> 	properly...
> To: <[email protected]>,	<[email protected]>
> Cc: 'Rafa?l Carr?' <[email protected]>,	'Jean-Paul Saman'
> 	<[email protected]>
> Message-ID: <843C7BD9186E49E1BE7EC431C9B79032@Socrates>
> Content-Type: text/plain; charset="utf-8"
>
> Folks:
>
>             [Editorial Aside ? please tell me what is the right mailing
> list to send this message to? I looked at the archive for
> [email protected] ? and it doesn?t look like real discussion
> happens there; there was some real discussion on the streaming list].
>
>
>
>
>
>             I?ve noticed that when you try to play a rtsp movie with VLC
> and read from Windows Media Server, there are problems detecting the end of
> stream.
>
>
>
> I?ve tested this with the 0.8.6f build (on WinVista), and the 0.9 daily
> build trunk-20080514-0003 on Windows XP.
>
>
>
> This function was pretty badly broken on the 0.9 daily builds (video just
> started and then dropped out entirely), but as that?s unreleased, we?ll
> ignore that.
>
>
>
> But on 0.8.6f, it comes close to working. It plays the video all the way
> though, but then fails to detect the end of the video.
>
>
>
> Noodling around about with WireShark, Windows Media Player (which of course
> plays the video just fine), and the VLC 0.8.6f source code, I?ve come to
> suspect the problem stems from how VLC (and MSFT) handle End-Of-Stream
> detection.
>
>
>
> Looking a streams of packets from WireShark, with WMP
>
>
>
> Request: DESCRIBE rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv
> RTSP/1.0\r\n
>
> ?..Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch,
> com.microsoft.wm.eosmsg, com.microsoft.wm.predstrm,
> com.microsoft.wm.startupprofile\r\n
>
>
>
> Reply: RTSP/1.0 200 OK, with session description
>
>
>
> RTSP  GET_PARAMETER rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv
> RTSP/1.0
>
> RTSP  Reply: RTSP/1.0 200 OK
>
> ?Content-type: application/x-rtsp-packetpair
>
> <<< OK ? now I think this packetpair thing is a red-herring, but I?ll leave
> it in, just in case it?s relevant>>>
>
>
>
> RTSP  SETUP rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/audio
> RTSP/1.0
>
>                         ?
>
>             Then a bit of video flies by?, and then I get:
>
> RTP   PT=Unknown (96), SSRC=0x84A7C509, Seq=3112, Time=21713, Mark
>
> RTP   PT=Unknown (96), SSRC=0x84A7C509, Seq=3113, Time=21733, Mark
>
> RTSP  Request: SET_PARAMETER
> rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv RTSP/1.0\r\n
>
> Content-type: application/x-wms-extension-cmd
>
> X-Notice: 2101 "End-of-Stream Reached"\r\n
>
> RTP-Info:
> url=rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/audio;Seq=3116,
> url=rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/video;Seq=5632\r\
>n
>
> RTP   [TCP Out-Of-Order] PT=Unknown (96), SSRC=0x84A7C509, Seq=3114,
> Time=21919, Mark
>
>
>
>             Reading between the lines, I inferred from the
> com.microsoft.wm.eosmsg ?supported? string means that WMS is using some
> non-standard way to signal end-of-stream. Given that they aren?t complete
> idiots at MSFT (and a few other hints I?ve gleaned from googling around), I
> infer that there must be some flaws the default RTSP end-of-stream
> algorithm.
>
>
>
>             And from the (significantly edited down) sequence of RTSP/RTP
> packets, I inferred that when the client gets the ?end-of-stream reached?
> message, it stops playing video.
>
>
>
>             Now ? there are lots of details I don?t understand here about
> what MSFT is doing here, including why the end-of-stream comes with an
> ?RTPInfo? indicating that its sent 3116 CSeq?s, but it has really only sent
> 3113 (or 3114 if you count the one just after the RTSP packet).
>
>
>
>             Now, when I look at the WireShark output from VLC <----> WMS, I
> see somewhat similar exchanges at the beginning:
>
> RTSP  OPTIONS rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv
> RTSP/1.0
>
> RTSP  Reply: RTSP/1.0 200 OK
>
> Supported: com.microsoft.wm.srvppair, com.microsoft.wm.sswitch,
> com.microsoft.wm.eosmsg, com.microsoft.wm.fastcache,
> com.microsoft.wm.packetpairssrc, com.microsoft.wm.startupprofile\r\n
>
>
>
> RTSP  DESCRIBE rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv
> RTSP/1.0 RTSP/SDP    Reply: RTSP/1.0 200 OK, with session description
>
>
>
> RTSP  SETUP rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/audio
> RTSP/1.0
>
> RTSP  Reply: RTSP/1.0 200 OK
>
>
>
> RTSP  SETUP rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/video
> RTSP/1.0
>
> Transport: RTP/AVP;unicast;client_port=56518-56519
>
> Reply: RTSP/1.0 461 Unsupported Transport
>
> RTSP  SETUP rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/video
> RTSP/1.0
>
> Transport: RTP/AVP/TCP;unicast;interleaved=0-1
>
> RTSP  Reply: RTSP/1.0 200 OK
>
> Cache-Control: x-wms-content-size=836560, no-cache, no-user-cache,
> private\r\n
>
> ?.
>
>
>
>             A little video playing later
>
>                         ?.
>
>
>
> RTP   PT=Unknown (96), SSRC=0x46B01221, Seq=22340, Time=21733, Mark
>
> RTSP  [TCP Previous segment lost] SET_PARAMETER
> rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv RTSP/1.0
>
> Content-type: application/x-wms-extension-cmd
>
> X-Notice: 2101 "End-of-Stream Reached"\r\n
>
> RTP-Info:
> url=rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/audio;Seq=33214,
> url=rtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/video;Seq=22343\r
>\n
>
> RTP   [TCP Out-Of-Order] PT=Unknown (96), SSRC=0x46B01221, Seq=22342,
> Time=22105, Mark
>
>
>
>             OK ? at least with VLC ? I got a little closer on the sequence
> numbers ;-). I?m really new to this, so I?m not really sure what to
> expect?.
>
>
>
>             Anyhow ? VLC did get the message. But it appears to ignore it.
>
>
>
>             Now ? its time to turn to c-code spelunking ?.
>
>
>
>             It appears the relevant bit of code would be in
> vlc-0.8.6f\modules\demux\live555.cpp.
>
>
>
>             In the routine static int Play( demux_t *p_demux ) we have:
>
>         if( p_sys->i_timeout <= 0 )
>
>             p_sys->i_timeout = 60; /* default value from RFC2326 */
>
>
>
>         /* start timeout-thread only on x-asf streams (wms), it has rtcp
> support but doesn't
>
>          * seem to use it for liveness/keep-alive, get_parameter seems to
> work for it. get_parameter
>
>          * doesn't work with dss 5.5.4 & 5.5.5, they seems to work with
> rtcp */
>
>
>
>             This suggests to the na?ve reader that you are implementing a
> stream-end-detection strategy based on the rtcp keep-alive mechanism.
>
>
>
>             Then in the code:
>
> static int Demux( demux_t *p_demux )
>
>             ?
>
>     /* Check if we need to send the server a Keep-A-Live signal */
>
>     if( p_sys->b_timeout_call && p_sys->rtsp && p_sys->ms )
>
>     {
>
> #if LIVEMEDIA_LIBRARY_VERSION_INT >= 1138089600
>
>         char *psz_bye = NULL;
>
>         p_sys->rtsp->getMediaSessionParameter( *p_sys->ms, NULL, psz_bye );
>
> #endif
>
>         p_sys->b_timeout_call = VLC_FALSE;
>
>     }
>
>                         I?m not really sure what this means (my next steps
> are to get the live555 library and try debugging that too), but seemed
> possibly relevant, given earlier comments about using RTP keep-alives to
> detect the end of the stream.
>
>
>
>
>
>             Not having the source for the live555 library, I haven?t get
> figured out exactly how the vlc live555.c demux code gets callbacks, but it
> appears maybe through the ?Control? function in demux\live555.c?  If so ?
> the next question would be ? is the underlying library catching this
> End-Of-Stream message and passing it to the control function, which is
> ignoring it? Or how do I fix the control library to look for this end of
> stream message.
>
>
>
>             Of course, at this point, I still don?t? know QUITE enough to
> actually tell VLC about the end of stream ? if I got the message, but I
> think I?m getting close to that point.
>
>
>
>             I?m anxious to collaborate with anyone else interested in
> making VLC work properly with Windows Media Server to correct this (and
> some related) problems.
>
>
>
>
>
>                                     Thanks,
>
>
>
>                                                 Lewis.
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mailman.videolan.org/pipermail/streaming/attachments/20080515/730e09
>f9/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> streaming mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/streaming
>
>
> End of streaming Digest, Vol 12, Issue 2
> ****************************************



-- 
GetWellNetwork, Inc. 
Charles Hordis * Senior Software Engineer
7920 Norfolk Avenue * 11th Floor * Bethesda, MD  20814 
mobile 267-992-2328 
[email protected]
www.getwellnetwork.com
_______________________________________________
streaming mailing list
To unsubscribe or modify your subscription options:
http://mailman.videolan.org/listinfo/streaming