On Tue, May 19, 2009 at 2:18 PM, David Singer
<singer at apple.com> wrote:
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.
So you force the content to be fragmented (with no direction on how to fragment) just to trigger a playlist reload?
- 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.
Yes, it was discussed earlier. John Lazzaro raised some questions that were raised several years ago in regards to this being a bad idea. I have not seen anyone from Apple respond to that.
- 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.
I'd like to hear more about that. It seems that your real-time polling interval is controlled indirectly by the size of the file (see above). Yet once you provide for trick play this stops being time-based. This seems to be a distinctly weak approach to controlling polling.
It would help if you wanted to take this approach to delve into the why behind some of the choices. I infer that you want distinct URI for each file fragment so that you can control caching - but there are other ways to control caching. You could, for example, have a single URI that clients poll to see if there is a new playlist available. The approach you outline seems to have ideas behind it aimed at accomplishing certain things, but those are not called out at all. Those of us that have been working on these kinds of things for years are wondering if you are trying to re-invent the wheel (or just to get a standard for something you already built).
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).
Yes, that makes sense.
I also raised questions about the choice of playlist format - specifically using a non-standards-based audio playlist format instead of something like SMIL that was designed for this kind of thing. Comments on that?
Greg