Re: [httpstreaming] FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01

[Thomas Stockhammer <[e-mail]>]

Experts,

Here are my initial comments:

Abstract:
- private -> proprietary

Introduction:
- The first sentence is messed, it mixes singular and plural
- The list of codecs, formats, players, platforms in the first  
sentence is quite arbitrary and more confusing than helpful
- Advantages on Adaptive Streaming over HTTP had been listed many  
times and a long time ago for example here:
	http://www.ietf.org/mail-archive/web/avt/current/msg11340.html
- 3GPP defines formats for MPD and Segments, including the Media  
Segment Format. Client behaviour is informative
- The ISO/IEC JTC1/SC29/WG11 (MPEG) work has progressed significantly  
to a committee draft. The committee draft is heavily based on 3GPP AHS  
and has the same objectives, namely the definition of the formats for  
MPD and segments.

3.1 3GPP
- PSS is a stReaming services, it is hot, but not as hot as you make it.
- A significant amount of the text in 3.1. is just copied from the  
spec. It may be sufficient to point to the spec. It is public.
- Some text in your document is sloppy, others is directly copied. I  
do not see any value to copy text as I said.

3.2 OIPF
- It is incorrect that your document introduces the extensions of the  
OIPF to 3GPP. The OIPF spec does this.
- The usage of normative text in your document seems inappropriate,  
like the "SHALL" in 3.2.2 and 3.2.3. Again, the OIPF spec is public  
and it is of no value to copy some text directly into this draft.

3.3 MPEG
- Again this is a pure copy of existing MPEG documents. A reference is  
sufficient.
- The information is outdated, as mentioned. Significant progress  
since MPEG#94


On 5)
5.1)
- It would be good to fix the typos
- 3GPP segments and MPD are defined by their MIME Types. The statement  
in your table on file endings is wrong.
	Please refer to the specifications:
		for MPD: MIME Type is vnd.3gpp.mpd, file extension is .3gm
		for Media Segment: MIME Type is  vnd.3gpp.segment, file extension  
is .3gs
- the steps in 1-3) are heavily simplified and this can only be an  
example. A client can act much differently, such as using byte ranges,  
parallel requests, etc. The server itself is also expected to be a CDN  
and is completely unaware of the contained media.
- I am not sure I understand the term "is encrypted into files"
- What do you mean "normal text file"?
- The intelligence in the Adaptive Streaming over HTTP is almost  
exclusively in the client, there is no negotiation
- The server software is typically considered standard HTTP/1.1, no  
specific intelligence. Some intelligence is needed in the preparation  
of the content, but this is typically no real-time process, at least  
for On-Demand video. Also for live "serving" and "preparation" are  
completely decoupled.

5.2)
- It is not correct that the 3GPP MPD needs to be updated even for  
live. If you use a template mode, the MPD stays static until some  
"unforeseen" event occurs. Client and Content Preparation have agreed  
on rules to construct URIs.
- If necessary, the MPD update happens asynchronously to the media  
decoding, so this is not considered to be a problem.
- I still heavily disagree with the push scenario as being viable.  
This assumes that there is a 1-1 relationship between the server and  
the client and the server is aware of the client's state. This is not  
in scope of any of the HTTP Streaming technologies that are referred  
to in your document. What you are proposing is more like advanced  
progressive download from dedicated servers. This had also been  
discussed in 3GPP, but is a different technology. It is server- 
enhanced progressive download and the client only issues a single HTTP  
request.
- There is for sure mechanisms to deliver important packets more  
reliably in HTTP - you just request it earlier. In anticipation of  
switching a smart client may also prepare such data. The client is  
intelligent.
- 3GPP defines QoE metrics that can reused also for HTTP Streaming.  
there will also be efforts in MPEG in including QoE.

5.3)
- The No in QoE monitoring seems to be wrong, the same on fast start- 
up, see above!
- The other 'No's seem to assume a different model on delivery and we  
should really check, if this is still in the scope. It seems to  
address generic HTTP delivery issues, not streaming specific aspects.

Best regards

Thomas




On Oct 25, 2010, at 1:29 PM, Ning Zong wrote:

> Hi, Folks,
>
> I have updated HTTP streaming survey and gap analysis draft and the  
> new
> version is as attached. You can also check the URL below:
> http://www.ietf.org/id/draft-zong-httpstreaming-gap-analysis-01.txt
>
> BR,
> Ning Zong
>
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[e-mail]]
> Sent: Monday, October 25, 2010 6:47 PM
> To: [e-mail]
> Subject: New Version Notification for
> draft-zong-httpstreaming-gap-analysis-01
>
>
> A new version of I-D, draft-zong-httpstreaming-gap-analysis-01.txt  
> has been
> successfully submitted by Ning Zong and posted to the IETF repository.
>
> Filename:	 draft-zong-httpstreaming-gap-analysis
> Revision:	 01
> Title:		 Survey and Gap Analysis for HTTP Streaming Standards and
> Implementations
> Creation_date:	 2010-10-24
> WG ID:		 Independent Submission
> Number_of_pages: 23
>
> Abstract:
> With the explosive growth of the Internet usage and increasing demand
> for multimedia information on the web, media delivery over Internet
> attract substantial attention from media industry.  To meet above
> requirements, HTTP Streaming technology is designed and gradually
> plays an important role in recent years.  Several leading Standard
> Development Organizations (SDOs) have been producing a series of
> technical specifications to define streaming over HTTP.  Moreover,
> several companies have devoted to developing private HTTP-based media
> delivery platform to provide high quality, adaptive viewing
> experience to customers.  Following a brief survey of existing HTTP
> streaming standards and implementations, this document gives a brief
> summary on these related work, analyzes the potential challenges
> especially from the network point of view, and lists the gap between
> existing work and possible working scope on the topic of HTTP
> streaming in IETF.
>
>
>
>
> The IETF Secretariat.
>
> <draft-zong-httpstreaming-gap- 
> analysis-01.txt>_______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming

---
Dr. Thomas Stockhammer (CEO) || [e-mail] || phone +49 89  
978980 02 || 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.