[streaming] Trying to understand why RTSP playing of video with a Windows Media Server source fails to find the end-of-stream properly
Charles R. Hordis
chordis at getwellnetwork.com
Fri May 16 15:25:44 CEST 2008
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 streaming-request at videolan.org wrote:
> Send streaming mailing list submissions to
> streaming at videolan.org
>
> 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
> streaming-request at videolan.org
>
> You can reach the person managing the list at
> streaming-owner at videolan.org
>
> 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." <lewis at sophists.com>
> 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: <videolan-devel at videolan.org>, <streaming at videolan.org>
> Cc: 'Rafa?l Carr?' <funman at videolan.org>, 'Jean-Paul Saman'
> <jean-paul.saman at m2x.nl>
> Message-ID: <843C7BD9186E49E1BE7EC431C9B79032 at 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
> videolan-devel at videolan.org ? 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
chordis at getwellnetwork.com
www.getwellnetwork.com
More information about the streaming
mailing list