Subject: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...

From: John Lazzaro <[email-masked]>
Date: Thu, 21 May 2009 14:46:44 -0700

Hi everyone,

Comments on draft-pantos-http-live-streaming-00.txt below.

What jumped out at me was that this is a late-1990s
approach to a problem ... but its almost 2010 ...

In my view, the I-D is trying to do for audio what the AJAX client code
for Google Maps does for image map tiles. Namely, pre-loading short
media files over HTTP, to drive a user interface that the user
perceives as continuous (and in the Google Maps case,
responsive to user input).

I haven't looked at HTML5 (yet), but I was under the impression
one goal of its audio/video features is to provide the
primitives to make it possible to implement the protocol
described in draft-pantos-http-live-streaming-00.txt using
AJAX techniques.  If the feature set isn't there yet in HTML5
to do that, I think the time spent working on this I-D is better
spent working within the HTML5 process to get the features that
are needed.  It seems to me that AJAX is a more natural way to
implement this sort of "concatenation of pre-downloaded 10-second
files" streaming.

If there is AVT consensus that draft-pantos-http-live-streaming-00.txt's
general approach is acceptable for a work-item, I'll do a second review
of potential technical issues with the protocol itself ...

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

---

From: Greg Herlein <[email-masked]>
Date: Thu, 21 May 2009 14:57:03 -0700

I concur.  I'm willing to help look at some of the underpinnings (MPEG
slitting/splicing for example) if there's sufficient interest that this
*approach* worth further effort.

Greg

On Thu, May 21, 2009 at 2:46 PM, John Lazzaro <[email-masked]>wrote:

> http://www.cs.berkeley.edu/~lazzaro<http://www.cs.berkeley.edu/%7Elazzaro>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

-- 
Greg Herlein
www.herlein.com

---

From: "Jaehwan Kim" <[email-masked]>
Date: Fri, 22 May 2009 12:28:01 +0900

Hi John,
It's cool idea!( although this playlist file looks 
not much heavy like an ordinary front page of many 
famous shopping portal sites, it's worth while).

And thanks for the good information about HTML5.

I think this draft would need to be enhanced in the end, 
(no matter what group decides to make it WG item), 
to consider many good applications already existed 
in different realm. 

Just I am thinking a KISS paradigm at the moment.

Regards,
Jaehwan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Lazzaro
Sent: Friday, May 22, 2009 6:47 AM
To: [email-masked]
Subject: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...

Hi everyone,

---

From: <[email-masked]>
Date: Fri, 22 May 2009 07:12:58 +0100

http://tools.ietf.org/id/draft-pantos-http-live-streaming-00.txt

There's a mismatch between the goal in the first sentence of
the introduction:

   This document describes a protocol for transmitting unbounded streams
   of multimedia data over HTTP [RFC2616].

and the focus of this draft on actually being limited to using
M3U files.

For unbounded streams where the length is not known a priori,
I was expecting to see heavy use of HTTP chunking.
That is not the problem that this draft is
trying to solve.

   Each media file URI MUST be preceded by an
   EXTINF tag.  Its format is:

   #EXTINF:<duration>,<title>

   "duration" is an integer that specifies the duration of the media
   file in seconds.  

So it's necessary to know how long a file is before specifying it.
The draft is not really dealing with an unbounded stream of data,
more bringing together separate known resources seamlessly. As John
says, that particular problem has been solved by AJAX.

cheers,

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of John Lazzaro
Sent: Thu 2009-05-21 22:46
To: [email-masked]
Subject: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...
 
Hi everyone,

---

From: Alex Giladi <[email-masked]>
Date: Fri, 22 May 2009 08:40:01 -0600

> http://tools.ietf.org/id/draft-pantos-http-live-streaming-00.txt
...
> more bringing together separate known resources seamlessly.

My $0.02:
 * If you break the incoming stream into smaller files, and announce
then as they become available, the approach is OK.
 * Though integer amount of seconds is a *bad* thing to do (since
framewise you will be off by up to 60 frames), a normal npt or SMPTE
timestamp would do better. Otherwise you require the encoder to
produce chunks. Perfectly rounded to a second. Anyway, given 29.97fps
framerate and 3-sec files, you'll be off by 1.8 minutes after an
hour...
--ag

---

From: Alex Giladi <[email-masked]>
Date: Fri, 22 May 2009 09:02:18 -0600

I think having some standardized way of streaming through HTTP is
something that actually may be needed on its own.
In many contexts you have to resort to a similar approach in some
hacky way. We know that people do this, why not have an interoperable
/ standardized way of doing this?

---

From: "Luby, Michael" <[email-masked]>
Date: Fri, 22 May 2009 10:20:50 -0700

I'm not expressing an opinion on whether this work should move forward at this point, but I'll make a couple of comments that everyone may not be aware of in terms of traction of this approach.

(1) Move Networks is essentially using this approach to provide their streaming solution.  (Used by ABC for streaming their prime time shows over the Internet, and many other content providers at this point).

(2) This is essentially the approach that Adobe FLASH is taking with their FLASH servers.  Perhaps in response to the market traction that Move Networks was getting.

(3) This same approach has also been adopted into Microsoft Silverlight.

Now, when I say this same approach, I mean that it can accommodate the following:

(A) Able to use standard servers (or cheap servers in general) to deliver the content, so that it can be delivered from a CDN or any other standard server farm.
(B) Real-time or Video-on demand streaming.
(C) Fast channel change and seek times, i.e., good responsiveness to user ADD.
(D) Able to automatically choose the initial streaming rate to match the initial available bandwidth.
(E) Able to seamlessly change streaming rate on the fly in reaction to changes in available bandwidth, even within a given content.
(F) Able to penetrate firewalls and NATS.

(A) is bolded, because it is perhaps the most important motivation for the approach and why it has become so successful.  (B-F) are what have become standard requirements for a true high quality streaming solution over the open Internet.  Move Networks technology exactly does A-F, using HTTP as the delivery protocol, much along the conceptual lines described by the draft.  I believe Adobe FLASH may use their proprietary protocols, but essentially they are achieving A-F using FLASH servers instead of HTTP servers.  I know that Silverlight has the functionality, but not sure if they use HTTP or something else as the delivery protocol.  All of these features seem to be attractive to streaming over the Internet, and is the most popular approach out there that is actually used in a massive way.

Using RTP directly for whatever reason has not caught on.   Perhaps some reasons RTP has not caught on: (a) An ad-hoc scalable infrastructure would need to be deployed for RTP video streaming, instead of using existing already scalable and deployed infrastructure.  CDNs are very adverse to having to support yet another type of server architecture, and are always trying to simplify what they need to support, not make it more complicated; (b) Not reliable;  (c) Firewall/NAT transversal in the deployed Internet is an issue; (d) No support for congestion control.

With respect to Ajax, it might help with some support for this approach in the client browser, and thus might be complementary to the proposal, but alone does not meet the requirements.
Mike

On 5/21/09 11:12 PM, "[email-masked]" <[email-masked]> wrote:

cheers,

L.

-----Original Message-----
From: [email-masked] on behalf of John Lazzaro
Sent: Thu 2009-05-21 22:46
To: [email-masked]
Subject: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...

Hi everyone,

---

From: Alex Giladi <[email-masked]>
Date: Fri, 22 May 2009 11:33:28 -0600

On Fri, May 22, 2009 at 11:20 AM, Luby, Michael <[email-masked]> wrote:
<...>
> (2) This is essentially the approach that Adobe FLASH is taking with their
> FLASH servers.  Perhaps in response to the market traction that Move
> Networks was getting.

see: http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol

Alex.

---

From: John Lazzaro <[email-masked]>
Date: Fri, 22 May 2009 11:54:32 -0700

On Fri, May 22, 2009 at 10:20 AM, Luby, Michael <[email-masked]> wrote:
> (A) Able to use standard servers (or cheap servers in general) to deliver
> the content, so that it can be delivered from a CDN or any other standard
> server farm.
> (E) Able to seamlessly change streaming rate on the fly in reaction to
> changes in available bandwidth, even within a given content.

[...]

> With respect to Ajax, it might help with some support for this approach in
> the client browser, and thus might be complementary to the proposal, but
> alone does not meet the requirements.

Given the right set of client browser primitives, could be be more specific
about which of your A-F requirements an AJAX approach could not meet,
and why?

---

From: "Luby, Michael" <[email-masked]>
Date: Fri, 22 May 2009 14:04:44 -0700

>From my limited understanding of Ajax (and it is very limited, believe me), it isn't audio/video specific, i.e., it doesn't specify video codecs to be supported, or video file delivery formats, or describe relationships between video/audio encoding streams that are required in order to do seamless stream transitions, as examples.  It seems that Ajax is possibly one of several ways that one might develop a client to support the functionality, but it is not streaming specific.

I guess it boils down to what is trying to be standardized.  If it is a general method for allowing the proposal to be implemented, then Ajax might be the answer.  If it is instead a standardized way to allow interoperable implementations of the proposal by different vendors/actors, i.e., different content providers use the proposal to prepare their video content for distribution, it is uploaded into and distributed using standard servers, and different clients written by different parties that implement the proposal can all play out the content, then one would need to specify the range of video and file formats supported, the metadata video file formats, the relationships between the files for the different video streaming rates, the constraints on the encoding of those video streams and formatting into files, etc.  Ajax might also be useful in this second case, but I don't think you would want to standardize all the things that would need to be standardized within an Ajax setting, as the standardization seems quite video specific, and perhaps it would make more sense to do this type of video-specific audio/video standardization in the AVT group.

On 5/22/09 11:54 AM, "John Lazzaro" <[email-masked]> wrote:

[...]

---

From: John Lazzaro <[email-masked]>
Date: Fri, 22 May 2009 14:50:53 -0700

On Fri, May 22, 2009 at 2:04 PM, Luby, Michael <[email-masked]> wrote:
> I guess it boils down to what is trying to be standardized.  If it is a
> general method for allowing the proposal to be implemented, then Ajax might
> be the answer.  If it is instead a standardized way to allow interoperable
> implementations of the proposal by different vendors/actors [...]

Thanks.  I believe that one step in reaching a decision on moving forward on
draft-pantos-http-live-streaming-00.txt is to get group consensus what
we should be
"trying to standardize" in this domain, given the choices you define
in the quote above.

---

From: Greg Herlein <[email-masked]>
Date: Fri, 22 May 2009 14:51:19 -0700

AJAX is probably not relevant to this conversation.  AJAX is a technique to
poll a server and dynamically update a web page without a full page
refresh.  Some aspects of AJAX are potentially applicable - like HTTP
polling, perhaps getting XML documents back with metadata/instructions,
etc.  I think if the media is being consumed in a browser then you want
these polls to happen in the background so you can make sure you have media
queued so that playback is seamless.

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.

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.  In fact, this is looking less and less to me like a protocol and more
and more like a REST API for a given video service.  I'll have to read the
doc again to see what kinds of special caching instructions might be
needed.  I skimmed that part on my earlier read.

Thoughts?

-- 
Greg Herlein
www.herlein.com

---

From: John Lazzaro <[email-masked]>
Date: Fri, 22 May 2009 15:08:30 -0700

>From the audio perspective, the last sentence may be a missing piece
of the puzzle
at the moment -- letting Javascript control the audio output queue in
a flexible way
to provide artifact-free concatenation of the small audio files that are being
downloaded in the background.  It's taking what we've learned about creating
audio APIs for operating systems over the past few decades, and adapting it
to the higher-latency world of scripting languages.

---

From: David Singer <[email-masked]>
Date: Fri, 22 May 2009 18:26:21 -0700

Well, not really comments on the draft; more to thank Mike for 
pointing out that there is a 'question' in the industry, and that 
perhaps existing techniques ('pure' RTP or MPEG-2 Transport or 
existing file download) are not working so well.

A few people at MPEG have noticed this as well, and are also asking 
the question.  It's by no means clear what should be done, or where, 
or by whom, but they are stepping up to holding an open workshop.  I 
don't get the sense from the organizers that there is any kind of 
'position' being taken here (yet), not even on whether or where 
something should be done, let alone what.

Have a look at this page and see whether some of you would like to 
write something (separately, jointly), or attend:
<http://multimediacommunication.blogspot.com/2009/04/workshop-on-mmt-modern-media-transport.html>
-- 
David Singer
Multimedia Standards, Apple Inc.

---

From: Roni Even <[email-masked]>
Date: Sun, 24 May 2009 01:36:41 +0300

Hi,
I find this draft interesting and also the MPEG workshop. I think that is
will be good to describe first the general problem that need to be addressed
before jumping to a solution and the MPEG work shop has more general scope
in the topics to be considered.

Industry experience of multimedia transport

Delivery of media over IP networks in ptp/ptmp manner
Download and random access of MP4 files
MPEG TS Transport between heterogeneous network
Delivery and sharing of User created contents

Challenges of emerging multimedia transport environments:

Peer-to-Peer (P2P) traffic for IPTV services
Cross-layer designs to improve the Quality of Service/Experience (QoS/QoE)
Context- and Content-Aware Networks
Conversion between a stream and a randomly accessible file

We can continue to discuss this in the AVT mailing list but I am trying to
see what is the place for the work since it relates also to other working
group. 

I hope that you are all aware on the p2p streaming discussion that took
place in the last two IETF meetings as BAR BOFs.

Regards
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David
Singer
Sent: Saturday, May 23, 2009 4:26 AM
To: [email-masked]
Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...

<http://multimediacommunication.blogspot.com/2009/04/workshop-on-mmt-modern-
media-transport.html>

---

From: Greg Herlein <[email-masked]>
Date: Sat, 23 May 2009 16:21:23 -0700

> > place in the last two IETF meetings as BAR BOFs.

Are there minutes of the p2p streaming meetings?

-- 
Greg Herlein
www.herlein.com

---

From: Victor Pascual Ávila <[email-masked]>
Date: Sun, 24 May 2009 09:32:01 +0200

> Are there minutes of the p2p streaming meetings?

http://www.ietf.org/mail-archive/web/ppsp/current/msg00158.html
http://www.ietf.org/mail-archive/web/ppsp/current/msg00157.html

More info: http://labs.chinamobile.com/ppsp/ietf

Cheers,
-- 
Victor Pascual Ávila

---

From: Greg Herlein <[email-masked]>
Date: Sun, 24 May 2009 13:34:20 -0700

Thanks Victor.  I found this too:
http://labs.chinamobile.com/attachments/Yunfei-Zhangs-problem-statement-Slides.pdf

That helps articulate the problem we are trying to solve.

2009/5/24 Victor Pascual Ávila <[email-masked]>

-- 
Greg Herlein
www.herlein.com

---

From: Thomas Stockhammer <[email-masked]>
Date: Mon, 25 May 2009 16:33:26 +0200

Dave, all,

DVB has started a similar effort in a study mission and a  
questionnaire. Contributions of DVB and non DVB members are welcome.
http://www.dvb.org/news_events/news/internet-tv-questionnaire/index.xml

Best regards

Thomas

On May 23, 2009, at 3:26 AM, David Singer wrote:

> <http://multimediacommunication.blogspot.com/2009/04/workshop-on-mmt-modern-media-transport.html 
> >
> -- 
> David Singer

---
Dr. Thomas Stockhammer (CEO) || http://www.nomor.de || phone +49 89  
978980 02 || cell +49 172 5702667
Nomor Research GmbH  -  Sitz der Gesellschaft: München -  
Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 -  
Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.

---

From: Greg Herlein <[email-masked]>
Date: Mon, 25 May 2009 10:15:29 -0700

In a shameless plug for us all, I blogged about this subject, for what it's
worth.

http://www.herlein.com/index.php?entry=entry090525-092231

-- 
Greg Herlein
www.herlein.com