Re: [httpstreaming] Discussion summarization in Dispatch on HTTP Streaming

[Thomas Stockhammer <[e-mail]>]

Dear Qin,

you are absolutely right that 3GPP has exclusively and purposely focused on formats, that can be delivered through standard HTTP infrastructures (CDNs, HTTP servers, HTTP proxies, etc.). The specification focusses on describing the relationship and formats of "segments" and segments are resources that are made available to the client as http-URIs. This enables service providers to use these formats together with existing web cache infrastructures.

There are many many good reasons for this and they had been discussed a year ago on the AVT mailing list when Apple submitted their draft. There were also opinions that RTP/UDP is good enough for streaming and streaming over HTTP is not the way to go.

However, there is always a simple answer to why Adaptive Streaming over HTTP as today is justified and you have it in you e-mail below as well: "It works!" And maybe even more important: "It is heavily used"

The decoupling of the video streaming application from a dedicated service and delivery infrastructure is what makes it so interesting. 

If there is a general problem on how to massively scalable deliver data through HTTP, then this problem seem to be non-specific to streaming, isn't it? And please consider that there are ways to feed HTTP caches with protocols other than HTTP/1.1, such as FLUTE.

Best regards

Thomas




On Sep 28, 2010, at 7:08 AM, Qin Wu wrote:

> Hi, Daniel:
> I agree it is a good idea to craft one gap analysis to compare different works in various SDOs than IETF.
> Since we haven't done anything in IETF ,I am difficult to see any overlapping with other SDOs,:-).
> Also in order to stimulate some discussion on this, I would like to share some of my views. In my personal opinion, It seems what other SDOs have standardized is very few. e.g.,
> 3GPP:
> The only two components developed by 3GPP are Media presentation Description and one streaming media file format.
> MPEG:
> MPEG hasn't specified any solution for how to employ HTTP streaming to support MPEG Media except publishing Uses Cases and requirements for HTTP Streaming of MPEG Media
> OIPF:
> OIPF didn't specify anything except adoption of 3GPP approach.
> Look at these works in 3GPP/MPEG, it seems they more rely on Browser Client to do many things, e.g., load/reload media presentation  description, control local playback, e.g., pause, resume by holding on segement request and reissuing segment request. What they require from network? Nothing. So what they are doing seems only to provide some component like Media presentation description and give some guideline on how to use this component
> in HTTP streaming to support limited adaptive capability? For the browser client behavior and implentation, I think W3C is right place to standardize browser behavior. Is it enough? Is it efficient? Is it sufficient to support real time streaming?
> In my opionin, these approaches developed by 3GPP more depend on existing infrastructure and pretty much easy to get some kind of service to market without any invest and effort from network provider and service provider. It works, But how to offer operators a more manageable and sustainable content services environment and, ultimately, lower costs is very painful and challenging.
>  
> Regards!
> -Qin
> ----- Original Message -----
> From: Daniel Park
> To: Qin Wu
> Cc: [e-mail]
> Sent: Saturday, September 25, 2010 3:33 PM
> Subject: Re: [httpstreaming] Discussion summarization in Dispatch on HTTP Streaming
> 
> Good to see this activity within IETF and highly welcome.
> 
> As you described below, there are already several SDO activities, and particularly they have their own direction and schedule toward the market. http-adaptive streaming (MS) and http-live streaming (Apple) are already implemented in the commercial level. 
> 
> I believe, IETF should pay attention to the coordination among the existing activities/solutions, and particularly clarify the role for each in order not to make a duplication. Otherwise, this activity will be very confused in the market. Why ? It is because IETF rides in the train too late unfortunately.
> 
> For doing that, gap analysis on the existing methods is the first, then we will be able to see which areas should be done by IETF based on the results of analysis. This direction seems very acceptable to me. 
> 
> Anyway, I support, and hope to move it forward quickly.
> 
> 
> Daniel
> -- 
> Soohong Daniel Park
> http://www.soohongp.com
> 
> 
> 2010/9/25 Qin Wu <[e-mail]>
> Hi, folks:
> Glad to see this discussion list has been created with the support of all of you.
> Summarized what we discussed in the DISPATCH mailing list on HTTP Streaming, couples of things were well discussed:
> 1. Does this work worth being done?
> Most of people speaked up on the list answer Yes since HTTP streaming is becoming more prevalent, large part of Internet Traffic today has been  possessed by HTTP Streaming, CDN and Direct Download.
>  
> 2. Is there any existing related work ongoing in IETF and other SDO?
> This questions haven't been explicitly discussed. But I think it is necessary to bring out on the table since we need more input from these existing work
> and coordination between different group on the same topic is requried.
>  
> So,Yes, we have lots of related work listed as follows:
>  
> (a).IETF:
>  
> HTTP Streaming Problem Statement
> discuss the issues when delivering high quality contents to browser users.
> The related draft is available at:
> http://tools.ietf.org/html/draft-wu-http-streaming-optimization-ps-00
>  
> Apples' HTTP live streaming: 
> well known for quite some time and implemented in the iPhone. It makes use of a M3U playlist file which serves as manifest and each media file must be formatted as an MPEG-2 Transport Stream or an MPEG-2 audio elementary stream.
> Movstreaming: is already deployed but also highly proprietary. However, it works with common media players. 
> The related work is avaiable at:
> http://tools.ietf.org/html/draft-pantos-http-live-streaming-04
>  
>  
> (b). IETF: Websocket protocol
> Focus on browsing acceleration, devloped by Hybi WG,As one complementary work, W3C standardize websocket API
>  
> (c).W3C' focus on client implentation bulit into browser,e.g., video playback support using script and html, push notification support using API, video support using Media fragments URI.
>  
> (d).3GPPs' Adaptive HTTP Streaming (AHS): 
> introduced recently which defines a Media Presentation Description (MDP) 
> and extensions to the well known ISO Base Media File Format.
>  
> (e).Open IPTV Forum (OIPF): 
> has been published on Sep 7th, 2010 including "HTTP Adaptive Streaming" which adopts 3GPP AHS and adds support for MPEG-2 Transport Stream. The related work is available at:
>  
> (f).MPEG' HTTP Streaming of MPEG Media : 
> MPEG has published Uses Cases for HTTP Streaming of MPEG Media and Requirements on HTTP Streaming of MPEG Media. The next stpe is to standardize a solution that addresses the need on how to employ HTTP Streaming to support MPEG MEdia.Therefore MPGE issued a call for proposals on HTTP streaming of MPEG media.
> Therefore Standardiztion related to this work needs to be carried out joint by IETF/W3C/3GPP . Overlapping work and efforts will be contributed to and synchronized 
> with these other relevant groups.
>  
>  
> 3. Given various onging work in other SDOs than IETF and vairous different implementations developed by industries (e.g.,Apple, Microsoft, Adobe, RealNetwork), what contribution IETF could make?What's the potential work item? what kind of problem do we need to solve?
>  
> Yes, it is clear IETF folks has expertise to do this work. The potential problems and issues the IETF folks are interested to look at and discuss are:
> (a). Issues involving real-time considerations and interoperability with other streaming techniques
> (b). Consideration of transportissues (fairness, delay, etc.)
> (c). Tweaking HTTP to improve streaming performance
> (d).Guidance on how to use HTTP in a network-friendly way.
> (e). Coordination with other protocols developed by IETF.
> (f). Offer better transport better than TCP (like SCTP), better tailored for the needs for streaming over http.
> (g). how to work in environments that may use a combination of RTP multicast and HTTP unicast.
> (h). How to deliver streaming contents to the client on any device with the same TV Quality of Experience.
> As for playlist format and streaming file format, these works have been specified by 3GPP, followed by MPEG/OIPF,probably not the interesting piece for the IETFers
>  
> If I miss something or you have any further inputs and suggestions/comments, please speak up on the list.
> Based on these inputs and proposals, I would like to share our thoughts thus far on what  a new charter might
> look like and will post in a separate email to this discussion list. The feedback would be highly useful at this point.
>  
> BTW:
> Since we have created separated mailing list for this topic, if you have any comments/ideas/proposals to share, please post
> them to the new discussion  list.
>  
> Regards!
> -Qin
>  
>  
>  
> 
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming
> 
> 
> 
> 
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming

---
Dr. Thomas Stockhammer (CEO) || [e-mail] || phone [phone] || cell [phone] || http://www.nomor-research.com
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.