No subject
Tue Mar 18 21:24:51 CET 2008
server=20
and client), the basic problem is that RTSP 1 has no standard =
end-of-stream=20
mechanism at all, which seems kind of a glaring omission to me. There =
are a=20
couple of mechanisms in various not-totally-standard implementations, =
and=20
some of those are being debated for RTSP 2.0. I did not find anything=20
implemented in VLC but I looked mainly in 0.8.6.
Hacking the ANNOUNCE message (meant for announcing available streams) =
seems to=20
be in the lead as an RTSP end-of-stream message now. It's something I =
may=20
need to implement in the next weeks or months, if I do I will submit a =
patch. =20
However that probably will not help you with WMS. Hacking the =
SET_PARAMETER=20
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=3D"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=3DUnknown (96), SSRC=3D0x84A7C509, Seq=3D3112, Time=3D21713, =
Mark
>
> RTP PT=3DUnknown (96), SSRC=3D0x84A7C509, Seq=3D3113, Time=3D21733, =
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=3Drtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/audio;Seq=3D3=
116,
> =
url=3Drtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/video;Seq=3D5=
632\r\
>n
>
> RTP [TCP Out-Of-Order] PT=3DUnknown (96), SSRC=3D0x84A7C509, =
Seq=3D3114,
> Time=3D21919, 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=3D56518-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=3D0-1
>
> RTSP Reply: RTSP/1.0 200 OK
>
> Cache-Control: x-wms-content-size=3D836560, no-cache, no-user-cache,
> private\r\n
>
> ?.
>
>
>
> A little video playing later
>
> ?.
>
>
>
> RTP PT=3DUnknown (96), SSRC=3D0x46B01221, Seq=3D22340, Time=3D21733, =
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=3Drtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/audio;Seq=3D3=
3214,
> =
url=3Drtsp://dev-wms.highwinds.com/abcdefgh/wms/pinball.wmv/video;Seq=3D2=
2343\r
>\n
>
> RTP [TCP Out-Of-Order] PT=3DUnknown (96), SSRC=3D0x46B01221, =
Seq=3D22342,
> Time=3D22105, 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 <=3D 0 )
>
> p_sys->i_timeout =3D 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 >=3D 1138089600
>
> char *psz_bye =3D NULL;
>
> p_sys->rtsp->getMediaSessionParameter( *p_sys->ms, NULL, =
psz_bye );
>
> #endif
>
> p_sys->b_timeout_call =3D 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/730e=
09
>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
> ****************************************
--=20
GetWellNetwork, Inc.=20
Charles Hordis * Senior Software Engineer
7920 Norfolk Avenue * 11th Floor * Bethesda, MD 20814=20
mobile 267-992-2328=20
chordis at getwellnetwork.com
www.getwellnetwork.com
_______________________________________________
streaming mailing list
To unsubscribe or modify your subscription options:
http://mailman.videolan.org/listinfo/streaming
More information about the streaming
mailing list