See also: IRC log
<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)
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: 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
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?
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
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
??: 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?
(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
<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
<Clarke> Thanks, ph
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[End of scribe.perl diagnostic output]