W3C home > Mailing lists > Public > public-media-fragment@w3.org > February 2009

RE: Relevant Protocols for Media Fragments

From: Davy Van Deursen <davy.vandeursen@ugent.be>
Date: Fri, 6 Feb 2009 16:06:33 +0100
To: 'RaphaŽl Troncy' <Raphael.Troncy@cwi.nl>
Cc: "'Media Fragment'" <public-media-fragment@w3.org>, "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
Message-ID: <004501c9886c$7fbabdc0$7f303940$@vandeursen@ugent.be>

Hi RaphaŽl,

>-----Original Message-----
>From: public-media-fragment-request@w3.org [mailto:public-media-
>fragment-request@w3.org] On Behalf Of RaphaŽl Troncy
>Sent: Wednesday, January 14, 2009 12:24 PM
>To: Silvia Pfeiffer
>Cc: Media Fragment
>Subject: Relevant Protocols for Media Fragments
>Dear All,
>Following a previous message from Silvia [1], I'm re-opening this
>discussion, see also a new wiki page [2]:
>> I have just edited the section
>> on protocols in the use cases and requirements document and removed
>> some discussion around which protocols we are covering and moved it
>> into the original use cases and requirements document at
>Basically, we agreed to consider mainly HTTP and RTSP, and Silvia added:
>> I did indeed research the protocol case and found that almost all p2p
>> protocols are proprietary, and that bittorent in particular already
>> has an internal mechanism for receiving fragments of media files
>> (http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29). p2p
>> protocols are mostly about receiving long files and playing them back
>> at a later time - so the need for addressing fragments doesn't seem to
>> be there.
>> As  for mms: it was deprecated by Microsoft in 2003 and is not even
>> supported in their latest software any longer.
>> These were the reasons that I thought neither mms nor the p2p
>> protocols were relevant to our work. However, feel free to disagree.
>> :)
>I would love to agree, but my recent experience told me I should not :-)
>Concretely, I went to my favorite portal to watch scientific talks,
>namely http://www.videolectures.net, a very large portal that contains
>videos synchronized with slides of all sort of scientific talks from
>conferences and lectures from all other the world in various
>disciplines, and it is growing very very fast! Among others, I could
>watch some of the talk I did, for example:
>Now, looking at the source of this page, I can get two streamable
>version of my talk:
>   - wmf format available through the mms protocol:

Although MMS is specified as protocol in the URL, this doesn't mean that the
media will be delivered through the MMS protocol. Microsoft has deprecated
the MMS protocol in favor of RTSP in 2003 (release of Windows Media 9
Series), as pointed out by Silvia. The confusing thing is that, although
Microsoft stopped supporting the MMS protocol, they still recommend using
'mms://' as "protocol rollover". Cited from [1]: "When a URL specifies
'mms://', the reader attempts to use the following protocols for data
delivery, in the following order:
   1. RTSPU (RTSP using UDP)
   2. RTSPT (RTSP using TCP)
   3. MMSU (MMS using UDP)
   4. MMST (MMS using TCP)
   5. HTTP".

Another interesting statement in [1] is as follows: "Windows Media Services
9 Series in Microsoft Windows Server 2003 will reject any MMSU or MMST
requests from a Windows Media Format SDK reader, because RTSP is the
preferred streaming protocol. Windows Media Services version 4.1 and earlier
do not support RTSP. In this case the reader object falls back to MMSU or

Hence, I tested which protocol is really behind
tc_01.wmv, and it turned out to be RTSPT (i.e., RTSP using TCP). Note that
ptc_01.wmv works in Windows Media Player. Therefore, I guess that in most of
the 'mms://' URLs, RTSP is used as underlying delivery protocol.

Best regards,


[1] http://msdn.microsoft.com/en-us/library/aa390673(VS.85).aspx 

Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems Multimedia Lab
URL: http://multimedialab.elis.ugent.be
Received on Friday, 6 February 2009 15:07:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:42 UTC