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

From: David Singer <[email-masked]>
Date: Fri, 5 Jun 2009 11:16:08 -0700

Greg, thanks for the comments.  Responses inline...

At 9:05  -0700 20/05/09, Greg Herlein wrote:
>>- 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.
>

We think that those minutes addressed a different idea. It's not 
clear that they apply to this protocol.

>>- 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. 
>

The protocol is tuned for large-scale, non-interactive, 
broadcast-style viewing. Clients can seek within the window presented 
by the playlist. They can implement fast-forward and reverse playback 
within it as well if they choose, but the protocol does not sacrifice 
scalability in return for additional "trickiness" that requires 
one-to-one interaction with the content provider.

>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?
>

We looked at SMIL. It's more complicated than M3U and doesn't add 
much value for our uses. We would have had to make a new SMIL profile 
and then extend it to add the same extensions to it that we need for 
M3U.

People who have experimented with the protocol tell us that 
they really like the simplicity of M3U, which makes it easy to do 
things like dynamic playlist generation.

At 14:51  -0700 22/05/09, Greg Herlein wrote:
>If I understand it, the objective of this effort is to leverage the web
>server infrastructure that is already understood and deployed in a way that
>can transport video.  The core use case is a desire to have some video
>source (which may be psuedo-live or recorded) and deliver it to thousands or
>millions of users over the existing internet.   The desire is to design a
>protocol that can operate on the traditional port 80 infrastructure in such
>a way that caching and CDN technology can scale the traffic.  Trick play and
>all playback is handled in the client and is outside the scope of the
>protocol.
>

That's correct.

>If I am correct, is there actually any need for a playlist?  I would suggest
>that all that is needed in a HTTP reply is the URI that will hold the next
>chunk of media and perhaps a time that the URIl will become active.  The
>client could then invoke the logic to go get that URI at the appropriate
>time.
>

We experimented with this approach, but it turns out that adding 
custom headers to the HTTP response is not particularly compatible 
with how the large CDNs work.

The playlist approach has another benefit, in that it allows content 
providers to express a window of previous content that a client can 
seek backward into.
-- 
David Singer
Multimedia Standards, Apple Inc.

---

From: Alex Giladi <[email-masked]>
Date: Fri, 5 Jun 2009 14:27:20 -0400

On Fri, Jun 5, 2009 at 2:16 PM, David Singer <[email-masked]> wrote:
<...>
> We looked at SMIL. It's more complicated than M3U and doesn't add much value
> for our uses. We would have had to make a new SMIL profile and then extend
> it to add the same extensions to it that we need for M3U.
> People who have experimented with the protocol tell us that they really like
> the simplicity of M3U, which makes it easy to do things like dynamic
> playlist generation.

What about ADI?

Alex.

---

From: David Singer <[email-masked]>
Date: Fri, 5 Jun 2009 14:59:45 -0700

>What about ADI?

hm...probably not "Aircraft De-Ice and Inhibitor". Less unlikely is 
"AutoCAD Device Interface". I guess we can hope for a link to the 
"American Distilling Institute", we can fear "Advanced Discriminating 
Interceptor", or tune in to "Acoustic Directional Intensity"...

or I could ask...which ADI do you speak of?
-- 
David Singer
Multimedia Standards, Apple Inc.

---

From: Roni Even <[email-masked]>
Date: Sat, 06 Jun 2009 11:12:56 +0300

David,
Adi means an ornament in my mother tongue (it is in the Bible). 
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David
Singer
Sent: Saturday, June 06, 2009 1:00 AM
To: Alex Giladi
Cc: [email-masked]; [email-masked]
Subject: Re: [AVT] iPhone streaming Internet-Draft posted

or I could ask...which ADI do you speak of?
-- 
David Singer
Multimedia Standards, Apple Inc.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Greg Herlein <[email-masked]>
Date: Sat, 6 Jun 2009 07:54:00 -0700

All:

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.
>
>  We think that those minutes addressed a different idea. It's not clear
> that they apply to this protocol.
>

They apllies to the idea of using HTTP to stream media, as far as I can
understand.  I'm sensitive to your desires but wonder about the
implementation/standard.  If there's a market for a solution that solution
will find a way to exist...  choosing a best good way for it to be
standardardized is a *good thing*

>
> The protocol is tuned for large-scale, non-interactive, broadcast-style
> viewing. Clients can seek within the window presented by the playlist. They
> can implement fast-forward and reverse playback within it as well if they
> choose, but the protocol does not sacrifice scalability in return for
> additional "trickiness" that requires one-to-one interaction with the
> content provider.
>

OK, 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?
>
>
> We looked at SMIL. It's more complicated than M3U and doesn't add much
> value for our uses. We would have had to make a new SMIL profile and then
> extend it to add the same extensions to it that we need for M3U.
>
> People who have experimented with the protocol tell us that they really
> like the simplicity of M3U, which makes it easy to do things like dynamic
> playlist generation.
>

"Because M3U is easy and SMIL is hard" seems like a poor reason to use to a
bunch of Engineers.  You are going to have to use extensions to couple it to
HTTP no matter what playlist format you use.  M3U is full screen only - no
regions or overlays can be done.  It's an audio playlist format after all.
Standardizing on M3U gives you absolutely no room later to do a multi-panel
(multi-region) display.

SMIL is not hard to use to do dynamic playlists.  It's no harder than M3U
really - perhaps a few hours more coding time up front.  Make a template,
drop in the data.  M3U is simpler because you can just 'cat' the elements to
the end and SMIL needs some tags to close it off.  It has the advantage of
being a multimedia playlist format that is standardized already, has
excellent reference documentation and even books written about it.  M3U has
nothing but a Wikipedia page, cannot support regions or any of the other
display control tags.  I predict that if you go the M3U route you will end
up organically growing that protocol to add things over time that SMIL
already has.   SMIL, as XML, can also be validated and thus check for
playlists that got borked somewhere.

> We experimented with this approach, but it turns out that adding custom
> headers to the HTTP response is not particularly compatible with how the
> large CDNs work.
>
> providers to express a window of previous content that a client can seek
> backward into.
>
> OK, I can buy that.  I think playlists are the right thing, but I wanted to
ask you why you did too.

-- 
Greg Herlein
www.herlein.com

---

From: Alex Giladi <[email-masked]>
Date: Sat, 6 Jun 2009 10:35:22 -0600

There are a couple of other meanings found in the wikipedia
(http://en.wikipedia.org/wiki/Adi)
As for possible descriptive languages, we have two options here: a
Tibeto-Burmese language and the CableLabs Asset Distribution
Interface.
;-)