Subject: [AVT] iPhone streaming Internet-Draft posted

From: Roger Pantos <[email-masked]>
Date: Fri, 1 May 2009 13:24:48 -0700

My apologies if this is a bit off-topic - it concerns Audio/Video  
Transport
rather than RTP specifically.

I just posted draft-pantos-http-live-streaming-00.txt:

    This document describes a protocol for transmitting unbounded  
streams
    of multimedia data over HTTP.  It specifies the data format of the
    files and the actions to be taken by the server (sender) and the
    clients (receivers) of the streams.  It describes version 1.0 of  
this
    protocol.

The complete draft  is available here:

https://datatracker.ietf.org/drafts/draft-pantos-http-live-streaming/

We appreciate feedback on the protocol. Please send it to
[email-masked].

thank you,

Roger Pantos
Apple, Inc.

---

From: Ross Finlayson <[email-masked]>
Date: Tue, 5 May 2009 09:39:57 -0600

>We appreciate feedback on the protocol.

Rather than invent yet another protocol, why not just implement a 
RTSP/RTP client on the iPhone instead?

(If you *really* want to do this over HTTP (though ideally only when 
direct RTSP/RTP connectivity is not available), you could use the 
RTSP/RTP-over-HTTP hack that QuickTime Player already uses.)

After all, there are plenty of people at Apple with expertise on this 
(but I dunno, perhaps they work in some other group? :-)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Greg Herlein <[email-masked]>
Date: Tue, 5 May 2009 08:56:46 -0700

I agree with Ross.   I cannot see any reason at all to invent a new
protocol.  If you want to keep the media inside a TCP connection then just
interleave it in the RTSP session.  If you want to make something really
useful then use RTP and support multicast.  I personally want a handheld
application that I can watch a streaming show sitting in the airport - not
over the cellular connection necessarily but over a local hot spot.   Hmmm,
maybe I should write that for my new Blackberry Bold (whose H.264 decode
seems beautiful).

Inventing a new protocol - however cool it is - just creates less
interoperability and more silo'd world.

Perhaps there's a reason for a new protocol?  Perhaps Apple could elaborate
on what problem they are trying to solve?

Greg

On Tue, May 5, 2009 at 8:39 AM, Ross Finlayson <[email-masked]>wrote:

> Rather than invent yet another protocol, why not just implement a RTSP/RTP
> client on the iPhone instead?
>
> (If you *really* want to do this over HTTP (though ideally only when direct
> RTSP/RTP connectivity is not available), you could use the
> After all, there are plenty of people at Apple with expertise on this (but
> I dunno, perhaps they work in some other group? :-)
> --
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

-- 
Greg Herlein
www.herlein.com

---

From: Alex Giladi <[email-masked]>
Date: Tue, 5 May 2009 10:58:35 -0600

Greg,
It's not entirely clear to me, but it looks from #4 that they are
looking at progressive download of segments vs. 'real' streaming. I
suppose one can do this with RTSP using PLAY request with closed time
ranges.
One problem that may happen with RTSP is that there may be overzealous
firewalls that blocks RTSP, but not HTTP.
Alex.

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 6 May 2009 01:38:10 -0700

> firewalls that blocks RTSP, but not HTTP.

This is becoming a sad reality. Despite all the great work developing
robust streaming protocols, "streaming" services over the public
Internet are increasingly required to adopt HTTP in order to get past
firewalls. Welcome to the Port80 network.

Greg

---

From: Alex Giladi <[email-masked]>
Date: Wed, 6 May 2009 10:58:22 -0600

Is there an RTSP-over-HTTP spec?

---

From: "Jaehwan Kim" <[email-masked]>
Date: Thu, 7 May 2009 12:13:57 +0900

http://developer.apple.com/quicktime/icefloe/dispatch028.html

Proposed live HTTP streaming based on MPEG-2 TS looks not bad.
I guess still IETF doesn't like a solution overusing HTTP port, but an end-user seems to like a high resolution video but no loss, whatever we use behind. 

Jaehwan

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 6 May 2009 20:36:30 -0700

Where does it say that it uses MPEG2 TS?

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jaehwan Kim
> Sent: Wednesday, May 06, 2009 8:14 PM
> To: Alex Giladi; [email-masked]
> I guess still IETF doesn't like a solution overusing HTTP port, but an end-user seems to
> like a high resolution video but no loss, whatever we use behind.
> 
> Jaehwan
> 
>

---

From: "Jaehwan Kim" <[email-masked]>
Date: Thu, 7 May 2009 13:49:20 +0900

Section 4 of the below one(the subject indicates this).
http://www.ietf.org/internet-drafts/draft-pantos-http-live-streaming-00.
txt

Jaehwan
-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Thursday, May 07, 2009 12:37 PM
To: Jaehwan Kim; Alex Giladi; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [AVT] iPhone streaming Internet-Draft posted

-acbegen

---

From: Greg Herlein <[email-masked]>
Date: Thu, 7 May 2009 08:06:53 -0700

I still think we don't understand the problem that is trying to be solved.
Aside from the core problem that is is a redundant protocol, I don't grok
some of the small details, like:

- in 6.1: "The server MUST divide the stream into individual media files
whose duration is approximately equal"
  - why?

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

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

In general, this protocol seems poorly thought out and appears to be trying
to solve a problem that has already been solved.  RTSP covers everything
this does, and supports trick play (this does not).  And provides a means to
cover AV protocols other than MPEG2.

Unless we don't understand the problem trying to be solved?

Greg

On Wed, May 6, 2009 at 9:49 PM, Jaehwan Kim <[email-masked]> wrote:

> txt<http://www.ietf.org/internet-drafts/draft-pantos-http-live-streaming-00.%0Atxt>
>
> Jaehwan

-- 
Greg Herlein
www.herlein.com