Re: [AVT] iPhone streaming Internet-Draft posted

[David Singer <singer at apple.com>]

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

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.