Subject: Re: [AVT] iPhone streaming Internet-Draft posted

From: David Singer <[email-masked]>
Date: Wed, 13 May 2009 12:24:12 +0800

Hi, Ross. Thanks for looking at the spec.

On May 5, 2009, at 8:39 AM, Ross Finlayson wrote:

>>We appreciate feedback on the protocol.
>
>Rather than invent yet another protocol, why not just implement a 
>RTSP/RTP client on the iPhone instead?

Distributing media as discrete files over HTTP gives content 
providers a cost-effective way to scale to high demand by using 
existing CDN and HTTP caching infrastructure.

With this goal in mind, we're looking for technical feedback on the 
specification.

thanks, nice to hear from you,

-- 
David Singer
Multimedia Standards, Apple Inc.

---

From: John Lazzaro <[email-masked]>
Date: Wed, 13 May 2009 14:54:12 -0700

From: Alex Giladi <[email-masked]>
> David,
> But why not re-use RTSP, just embedding it into HTTP?
> Alex.

This was proposed back in 2001 in MMUSIC, and did not
reach consensus, see the snippet below from the MMUSIC
minutes of IETF 51:

10. Tunneling RTSP/RTP/RTCP in HTTP (draft-gentric-avt-rtsp-http-00.txt)
=====================================================

RTSP describes a TCP-based streaming mode.  This includes interleaved
RTP/RTCP packets.  The draft proposal is to extend this to HTTP-only
firewalls.

Source of proposal: Internet Streaming Media Alliance.

The basic proposal is to use HTTP to create a channel in each
direction.  The authors are looking for more ideas and thoughts on how
to proceed.

Melinda Shore <[email-masked]> expressed her disagreement with the
proposal, because it raises serious security concerns.  Its whole
thrust is to violating site security policy.  It would be more
consistent with network policy to use Jonathan's SIP approach.  If the
draft is accepted, HTTP might become characterized as "Horrible
Trashcan Transport Protocol".  Jonathan Rosenberg noted that it is too
late to salvage HTTP's reputation: RFC 3093 "IP Over HTTP" already
describes how to do it.  Mark Handley also expressed his concern with
the security implications.  Port 554 is allocated for RTSP; managers
can open it if they want to.  Apparently some firewall vendors already
block strange uses of HTTP.  Site administrators are aware of this
sort of tunneling and are asking firewall vendors for controls.

Joerg Ott ruled that the responses he had heard make it clear that the
proposal is going nowhere in the MMUSIC WG.

-- 
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
john [dot] lazzaro [at] gmail [dot] com

---

From: David Singer <[email-masked]>
Date: Tue, 19 May 2009 14:17:25 -0700

Hi Alex, friends

Even when tunneled through HTTP,   RTP does not produce discrete 
files that can be cached and redistributed by CDNs. This is what 
enables HTTP live streaming to be scaled cost-effectively.

On May 13, 2009, at 10:16 AM, Alex Giladi wrote:

>On Wed, May 13, 2009 at 12:24 AM, David Singer 
><<mailto:[email-masked]>[email-masked]> wrote:
>
>>>Rather than invent yet another protocol, why not just implement a RTSP/RTP
>>>
>>>client on the iPhone instead?
>>>
>>
>>Distributing media as discrete files over HTTP gives content providers a
>>
>>cost-effective way to scale to high demand by using existing CDN and HTTP
>>
>>caching infrastructure.
>>
>>

---

From: David Singer <[email-masked]>
Date: Tue, 19 May 2009 14:18:24 -0700

Hello Greg. Here are some answers to your questions:

On May 7, 2009, at 8:06 AM, Greg Herlein wrote:

>- in 6.1: "The server MUST divide the stream into individual media 
>files whose duration is approximately equal"
>   - why?
>

This duration is used to tune the client retry interval when polling 
the playlist file. See section 6.2.3.

>- in 6.1: "The server MUST create a URI for each media file that 
>will allow its clients to obtain the file."
>
>   - why? Divide the stream into many files and then the client has 
>to know the file names and ask one by one?
>
As discussed earlier the protocol distributes media as discrete files 
via HTTP to enable use of its caching infrastructure.

>- in 2.0: "To play the stream, the client first obtains the Playlist 
>file and then obtains and plays each media file in the Playlist. It 
>reloads   the Playlist file as described in this document to 
>discover additional segments."
>  - in 6.1: "The server MUST create a Playlist file. The Playlist 
>file MUST conform to the format described in Section 3."
>  - in 3.0: "Playlists MUST be Extended M3U Playlist files [M3U]. 
>This document extends the M3U file format by defining additional 
>tags."
>     - so you take an audio playlist format and extend it instead of 
>using something like SMIL?  Why?
>
>- you specify a means to reload a playlist but not to signal a 
>client that there is a new playlist - so you poll.  Poor form.
>

Our experience is that polling is efficient if the client polls at 
the right time, and in a real-time playback system it is generally 
possible to achieve this.

We have not found a way to signal the existence of new media files 
that scales effectively (i.e. to the millions of simultaneous users).
-- 
David Singer
Multimedia Standards, Apple Inc.

---

From: Alex Giladi <[email-masked]>
Date: Wed, 20 May 2009 09:50:55 -0600

David, Roger:

A few of questions regarding the RFC:

3.
  * Is there some sort of a standardized definition of M3U you are
referencing? There is a reference [M3U], which is a link to Wikipedia,
which, in turn, is a moving target.

3.1.7.  EXT-X-STREAM-INF

  * What are the requirements on the MPEG-2 TS/PES here? Is PMT
expected to be in each file, or do you convey the relevant information
separately?
  * Why do you need to specify the codecs separately, if they are
already conveyed in the stream?

4.
  * E.g. in case of H.264, do you require SPS/PPS/SEI's in the
beginning of each file, or only in the beginning of time? If the
latter is correct, how do you start playing from an offset? Otherwise,
why these parameters cannot change (e.g. switch from 30000/1001 to
24000/1001)? What is the definition of "consistent parameters" in this
case?

6.1.3.  Providing variant streams
 * Does this mean that PTS values need to match in all variant
streams? What happens in case of different frame rates?

Thanks!

Alex.

---

From: David Singer <[email-masked]>
Date: Tue, 26 May 2009 10:02:36 -0700

Hi Alex

thanks for the helpful comments...

>which, in turn, is a moving target.

We're using that definition. We do not know of a better specification. It is
an informal standard, which is why the Internet-Draft specifies it as well.

>expected to be in each file, or do you convey the relevant information

We recommend putting PAT/PMT at the start of each segment.

>already conveyed in the stream?

The codecs are specified so that a client can reject the stream
without reading the media files.  We want to allow providers to create
a single playlist for clients with different capabilities.

>latter is correct, how do you start playing from an offset?

We recommend SPS/PPS/SEI along with each IDR frame.  We recommend
at least 1 IDR frame in a segment. This allows clients to join the
stream at any segment.

>Otherwise,

Section 4 refers to consistent encoding parameters within a single variant
stream, such as resolution and profile. Video frame rate is an exception
since clients can handle a change without reinitializing the decoder.

>streams? What happens in case of different frame rates?

All variant streams must share the same timeline, but video frames
do not have to line up exactly.

We're planning to revise the Internet-Draft to loosen the language
somewhat:

"Matching content in variant streams MUST have matching timestamps.
This allows clients to synchronize the streams."

(And thanks for your questions generally - they suggest a number of
places we need to tweak the Internet-Draft.)
-- 
David Singer
Multimedia Standards, Apple Inc.