<scribe> scribe: philipp

clarke: last meeting we decided not to escalate out bugs - had discussions with chair and W3c to review that decision - went back and forth

kept original decision

my understanding: bugs are being addressed - have not been escalated - seems they will be resolved as quickly as they can anyway

ph: has there been work on the bugs? estimate for a response?

clarke: will take action item to look at them this week - one chair suggested more work was needed on some

everyone else invited to make suggestion for more detailed solutions

<scribe> ACTION: clarke to forward info on which bugs need more work [recorded in http://www.w3.org/2012/01/19-webtv-minutes.html#action01]

<trackbot> Created ACTION-88 - Forward info on which bugs need more work [on Clarke Stevens - due 2012-01-26].

clarke: next item - new scope for group

see agenda for what we need

not sure we need to change mission statement

schedule work on once we have deliverables

scope: should add item - "concentrate on adaptive streaming and content protection issues"

change in deliverables most significant: implementation in script of manifest ... (see wiki page for exact text)

Deliverables

A proposed interface that will allow manifest files to be interpreted and adaptive bit rate to be implemented in script.

A proposed interface that will allow content protection to be implemented in a way that is independent of the underlying content protection method.

duncan: about adaptive: suggestion is to work around ... solution that's in chrome?

clarke: yes

duncan: rather than specific, should have more discussion about ... (certain topic) - parsing of manifest in javascript or do everything in the media player

clarke: so be more generic? look at more detailed info exchange between ua and api?

duncan: yes, sth like that

jason: really saying just looking for greater control mechanisms?

both optoins 2+3 are more individual control, granular control

s/optioins/options/

clarke: duncan, can you take a shot at that?

write proposed text, put on reflector

<scribe> ACTION: duncan to provide proposed text for adaptive bitrate deliverable [recorded in http://www.w3.org/2012/01/19-webtv-minutes.html#action02]

<trackbot> Created ACTION-89 - Provide proposed text for adaptive bitrate deliverable [on Duncan Rowden - due 2012-01-26].

clarke: what about content protection deliverable? comments?

have some concerns with my text myself

Mark(?): there are common features of all systems, they should be handled in a common way e.g. message sequence

clarke: wait with schedule until we have deliverables
... jason, work on bandwidth issue?

jason: yes - limit just video/streaming experience - hint to media player only

limit high-bandwidth streams

not a hard-cap - limit experience from playing top number of available streams wrt bandwidth

clarke: jason, please update with your suggested wording - resolved

ph: are deliverables specifications?

clarke: yes, solution proposals

<jasonlewis> CT1 use case is updated: http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Minimal_Control_Model_Proposal#Use_Cases

clarke: next item - continue discussion on CT2 - drop, (and other alternatives) .. media queries mentioned

has there been progress? opinions?

(silence)

Jan had thoughts - will check back with him

a few people were ok with just dropping it - certainly an option as well

who believes quality target in general is more beneficial than dropping requirement altoghether?

Bob: think it's good goal, but unless there's a way to express quality in adaptive bitrate independent manner, hard

looked at dash - there are attributes that are linked with quality like resolution

clarke: alternative is having parameterr for quality which is specific to the protocol

pass a string

makes it hard to be independend of the method

arguments in favor for that solution?

Mark: makes sense - there are simple things you could do - resolution - could do something similar to media queries - ... there may be other one or two things that are simple to do

we could do those, and then see what use cases are left that are not addressed - think set will be small

??: if we do quallity instead of bitrate - very subjective

reducing resolution is not only way to reduce bitrate - other parameters exist

if you have talking head, reduce framerate, but not in car race

so only say minimum bitrate, let owner of content decide what to change to reach that

Clarke: simplest one is bitrate - if you can't achieve, generate an error - decision how to adjust quality up to user agent which I like

maybe have a bitwise representation of various things - resolution, color-rate etc. - use agent strives for combination of those

not sure that makes sense though

??: two sides of this - content could be dynamic - and should have parameters: don't show this below certain bitrate

scribe: (gives example) ... need to know quality parameters for content

clarke: decision better handled by content itself rather than by webpage requesting content

mark: ... not clear what requirement is ...

why does user want to set this restriction?

clarke: think it's more the content provider - ensure that video is never macroblocked

somebody working at bitrate that causes macroblocking, don't show video

mark (audio macroblocked): ...

<mark> I'll try and fix my audio!

<mark> My point is just that the use-case seems to be a user who prefers rebuffering to low quality

<mark> I'm not sure that's an important usecase

??: ... could leave it optional to add metadata flag(?) - if no adequate content description, feature is bypassed

scribe:

jason: can we combine this with rep group change etc. parameters ... here's suggested minimum/maximum representation idea(?)
...

clarke: that makes more sense

whatever system you're playing on has some features - I am requesting content for HD-TV, so stream should be high bandwidth

makes more sense to me than specifying bandwidth

??: browser should report resolution capability of device, so server can decide what to do

clarke: yes

??: not consistent with adaptive bitrate philosophy - that info already provided as part of manifest file - there is resolution info in there

client makes determination, requests appropriate stream

requirement should be: make use of what's in manifest file

clarke: adaptive bitrate video is designed to always send best quality based on bandwidth available

??: not sure - client can choose the bandwidth, and different representations - always up to the client

what the client does may not work - but always client driven

clarke: client controls all this, and no quality paramet - let's assume this - client says: I only want to do this resolution, if I can't get it - adapt or quit

exploring whetehr there is reason for CT2, and less convinced it is

jason: could starting playback hint help?

add metadata and pass it up to the player

mark: adaptive streaming gives best quality by definition without rebuffering - when do I want to deviate?

hypothetical user that prefers buffering

or user wants more waiting at the beginning to get more quality

our experience: not many users are aware of this sort of stuff

dont' think many people will be interested, might be just confusing

it's something for the user to use, not for content provider

providerr will simply not provide level he doesn't want to send out

jason: there are case where advertisers make requirements

mark: interesting requirement - slightly different

say even in manifest - don't scale this stream

jason: some adaptive streaming techs don't support that

??: ability of web page author to know if content will play at appropriate quality and have option to react

clarke: client will know different encodings that are available - but won't know how much bandwidth it has

??: content provider will not encode at lower quality than they want it to be displayed in - ... - there will be case where content is not displayed - advertisers don't want gaping hole

not sure how to solve this

??: just buffer, continue playing at higher level

clarke: that's what people come to expect - things pause

content providerr, even ad provider, want to decide what they want to happen if min bandwidth not available

mark is right - easiest way to not have content displayed at lower resolution is not to provide it

??: mecvhanism for browser playing a page is not having succes in playing those - and then offer an alternative?

clarke: that's how adaptive streaming works - adapt to whatever bw is available

??: something of a lower level is being displayed is the problem - according to CT2 use case, we don't want it to drop to this level

??: desire that can't be met in physical implementationo

sounds to me like an error condition

content provider can avoid error condition by lower bw content in their adaptive stream

??: is there mechanism that that error message that content is not playing is captured, and replaced e.g. by still image until buffer is full?

mark: there is event that gets fired when playback stops

more question for video element/html5 group

??: do we need to be specific to adaptive streaming?

scribe:

(seems answer is no)

clarke: becoming convinced that we don't need CT2

suggest leave discussion open a little longer, but seems this is the conclusion

looking for cases to refute that

ph: who brought it up?

clarke: don't remember - maybe jan?

sounds good in theory, but details are messy

will summarize conclusion and ask for use cases that suggest we still need this

on reflector

<scribe> ACTION: clarke to check support for CT2 on mailing list [recorded in http://www.w3.org/2012/01/19-webtv-minutes.html#action03]

<trackbot> Created ACTION-90 - Check support for CT2 on mailing list [on Clarke Stevens - due 2012-01-26].

so what should we talk about next?

next week that is

call adjorned

<Clarke> Thanks, ph

sure

clarke, contacting you on private chat

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/groups/group/
FAILED: s/optioins/options/
Succeeded: s/speciffic/specific/
Succeeded: s/Glenn (?)/??/
Succeeded: s/startup/starting/
No ScribeNick specified.  Guessing ScribeNick: ph
Found Scribe: philipp

WARNING: No "Topic:" lines found.

Default Present: +1.908.848.aaaa, +1.908.848.aabb, +1.425.269.aacc, GlennAdams, Franck?, Duncan, Philipp, MarkW, Mark_Vickers, Mark_Watson
Present: +1.908.848.aaaa +1.908.848.aabb +1.425.269.aacc GlennAdams Franck? Duncan Philipp MarkW Mark_Vickers Mark_Watson

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Agenda: http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_19th_January_2012

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 19 Jan 2012
Guessing minutes URL: http://www.w3.org/2012/01/19-webtv-minutes.html
People with action items: clarke duncan

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report