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

From: Greg Herlein <[email-masked]>
Date: Wed, 20 May 2009 09:05:21 -0700

Comments inline

On Tue, May 19, 2009 at 2:18 PM, David Singer <[email-masked]> 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

-- 
Greg Herlein
www.herlein.com

---

From: John Lazzaro <[email-masked]>
Date: Wed, 20 May 2009 12:36:31 -0700

> seen anyone from Apple respond to that.

Just to clarify ... I posted the minutes from the AVT session of the IETF
meeting that shot down the earlier RTSP-over-HTTP standardization
attempt ... so that newcomers that are proponents of that approach
would know the AVT history behind the idea.  That was my sole intention,
at the moment I'm remaining neutral, since I haven't had time to read the
draft (yet).

As an aside, Vint Cerf gave a talk here at Berkeley a few years ago,
and he was rather pessimistic about the future of media streaming
technologies for stored content.  He felt that file downloads had
won the war for stored audio, and that video would follow the same path
once network bandwidth caught up, and that would happen sooner
than many people believe. Something to think about ...

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