[opendtv] Re: Apple to Provide Live Video Streaming of September 1 Event
- From: "Hughes Gary-DJWV76" <ghughes@xxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Fri, 3 Sep 2010 12:05:46 -0400
A couple of points..
- it has been submitted to IETF as a draft, not an RFC. May seem like a
nit, but in the standards world this is important. A number of SDOs are
scrambling to figure out their role in this brave new world (MPEG, DVB,
OIPF, 3GPP, ...)
- it is not streaming in the push, isochronous sense. It is a series of
short file downloads initiated by the client (pull model) and relies on
the client to pace the transfers and reassemble a stream from the
fragments. Again this may seem like a nit, but if you build servers it
is the difference between do I build/buy a semi-trailer or a couple of
dozen Hyundai sedans.
- use of RTP/RTCP would require synchronizing multiple elementary
streams and requires the active participation of the origin server. More
importantly it requires the public CDNs to build an overlay network
specific to the protocols in use. Using short HTTP GETs fits in nicely
with the existing caching HTTP based CDNs (this applies to MS
Smoothstream and Adobe Dynamic Streaming as well)
Even so, watching it from home (via Comcast internet) was not a banner
experience. Video quality was so-so, ok for news, not up to
entertainment standards. It kept dropping back to a 'B roll' feed of an
auditorium, unannounced, and I'd have to restart the session to get back
to Steve on stage. Presumably their new server farm was overloaded.
gary
Gary Hughes
Video Architect
Distinguished Member, Technical Staff
Motorola On Demand Video, MA34
80 Central St.
Boxborough, MA 01719
Email: ghughes@xxxxxxxxxxxx
Office: 978 266 7269
Mobile: 978 339 3615
Fax: 978 264 9108
> -----Original Message-----
> From: opendtv-bounce@xxxxxxxxxxxxx
> [mailto:opendtv-bounce@xxxxxxxxxxxxx] On Behalf Of Manfredi, Albert E
> Sent: Thursday, September 02, 2010 5:48 PM
> To: opendtv@xxxxxxxxxxxxx
> Subject: [opendtv] Re: Apple to Provide Live Video Streaming
> of September 1 Event
>
> Craig Birkmaier wrote:
>
> > Perhaps Bert would like to comment on the approach Apple has taken
> > with HTTP Live streaming, as it appears to be a viable work around
> > to UDP based streaming, making it possible to deliver
> multiple levels
> > of quality through the existing HTTP router infrastructure...
>
> I never paid a lot of attention to this, because it seems to
> be specifics added to streaming mechanisms that have been
> around a long time. This is not a fundamentally new protocol.
> It seems more like nitty gritty specified to make sure
> everything plays together as Apple intends. Others have done
> similar things in the past, thir own way.
>
> Among the specifics are encryption of the streams and
> encyption of the playlists. Cl;ients need to download the
> encrypted playlist before they can start a session. The
> precise mechanisms for this are described.
>
> There is an Internet Draft, dated 2009, and updated most
> recently in June 2010, that explains this new protocol.
>
> http://tools.ietf.org/html/draft-pantos-http-live-streaming-04
>
> It is based on HTTP, meaning RFC 2616. As such, the video
> streams are sent over TCP only, which means they cannot use
> IP multicast. Since IP multicast is, let's say, non-existent
> among different ISPs, I don't think that limitation amounts
> to much. But surely, we have all used other variants of HTTP
> live streaming, including the possibility of viewing at
> various quality levels, haven't we?
>
> One of the specifics is that Apple is restricting this to
> MPEG-2 TS formatting. For example, if they had based the
> streaming on RTP/RTCP, that MPEG-2 TS would not have been
> required. But that's a tradeoff, because doing it this way
> allows leveraging off HTTP, which must use a TCP Transport
> Layer. So, to keep the packets flowing at a steady rate,
> while using TCP, might as well go with MPEG-2 TS.
>
> Bert
>
>
> ----------------------------------------------------------------------
> You can UNSUBSCRIBE from the OpenDTV list in two ways:
>
> - Using the UNSUBSCRIBE command in your user configuration
> settings at FreeLists.org
>
> - By sending a message to: opendtv-request@xxxxxxxxxxxxx with
> the word unsubscribe in the subject line.
>
>
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
