Re: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur

Fair point, I was generalizing. To your point, it seems most platforms and media formats have different QoS metrics and APIs available; differing heuristics are obviously needed depending on what data points can be obtained.

I agree that trying to design a good Model 2 API will be very difficult. Especially in light of lack of standards around video formats, packagaing, and delivery of content to the video tag.

From: Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>>
Date: Tue, 13 Dec 2011 08:58:44 -0800
To: Jason Lewis <jason.lewis@email.disney.com<mailto:jason.lewis@email.disney.com>>
Cc: 이현재 <hj08.lee@lge.com<mailto:hj08.lee@lge.com>>, Clarke Stevens <C.Stevens@cablelabs.com<mailto:C.Stevens@cablelabs.com>>, "public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>" <public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>>
Subject: Re: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur


On Dec 12, 2011, at 11:45 PM, Lewis, Jason wrote:

Hi, in general I agree with the 3 architecture models as well.
For providing content, I think models 1 & 3 are most important:

Model 1:  Reporting & QoS mettrics are critical. When playing HLS in and
HTML5 player, we have no clear view of which bitrates are truly optimal.
Delivering to phones, tablets, and desktops across varying quality wifi or
3G networks can be like throwing darts blindfolded :)

Model 2: Nice to have, but the heuristics of selecting a bitrate based on
bandwidth & client decoding performance are pretty well understood.

Based on my work at Netflix, where we probably have one of the more advanced heuristics algorithms deployed, I would question this statement. I think there is a long way to go in understanding these heuristics.

But this is exactly why I am not so much in favour of Model 2 at this time (if the heuristics *were* well understood it might be possible to design a good API for model 2).

...Mark

Application developers shouldn't have to deal with this in order to
provide content to a customer.

Model 3: Dynamic client-side selection & appending of video segments (or
sources) is critical to present seamless video experiences to viewers.
Application developers capabilities on HTML5 generally lag behind in this
area.

I've also added three new use cases related to these thoughts:
http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Error_Codes#Use_Cases


Thoughts?  Thanks, J
--
Jason Lewis
Disney Technology Solutions and Services



On 12/12/11 6:18 PM, "이현재" <hj08.lee@lge.com<mailto:hj08.lee@lge.com>> wrote:

Hi Clarke,

I think the 3 architecture models approach on adaptive streaming you
proposed is very good.
At first, rather full media control approach will be easy to discuss
between companies for deciding what functionalities are needed for video
tag.
The utmost goal is surely minimal control approach which video tag object
will do agreed necessary functions automatically without application
developers intervention.

Let's hear content providers' and TV manufacturers' voice on what
functionalities are necessary.
Content providers and TV manufacturers, please speak up.

Best regards,
HJ / LG Electronics

-----Original Message-----
From:
Sent: 없음
To: Clarke Stevens; public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
Subject: RE: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur

Hello,

I have a couple of questions on the proposal.

1. segment definition
Can a definition of segment be added to the proposal? It will help go over
the below comments.

2. maxLevel (input)
What is the format of the input. Is it a segement identifier or bandwidth?
If it is agreeable I would recommend to adopt concept of bandwidth that is
mapped to the manifest bandwidth. Even though the bandwidth is a
subjective
level based on what is reported in the manifest rather than actual it is
the best form to indicate a max limit. An extra argument could also be
included indicating what position that this max level should be applied.
An
issue for implementers is that simply indicating max level may have
different effects depending on how the buffer is handled. If this can be
done at a future position it will make for a smoother transition.

3. callback change in representation
I am missing a callback reporting when the representation has changed. It
might be what is called segment in the proposal but I am not sure. This
callback is only reported when the "bandwidth" has changed. The "position"
at which this change occurs should also be included since it may occur in
a
future point.

Regards,
JanL

-----Original Message-----
From: Clarke Stevens [mailto:C.Stevens@cablelabs.com]
Sent: den 9 december 2011 20:01
To: public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
Subject: [MEDIA_PIPELINE_TF] Adaptive Bit Rate Architectur

Please take a look at the Wiki page for Adaptive Bit Rate.

http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Error_Codes


I'd like to have a good list of parameters, and errors (for model 1 in
particular) that we can provide for MPTF folks to review over the next
view
days. You can make suggested edits directly, or post your ideas to the
reflector.

Also, please make sure we are in agreement on the definitions of the
architectural models.

Thanks,
-Clarke