issue-34

<Clarke> issue-34: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Adaptive_Bit_Rate_Delivery

<trackbot> ISSUE-34 Adaptive Bit Rate Delivery notes added

duncan: have some internal discussion about the point 4
... how can we allow parameters?

clarke: what do you suggest?

duncan: a way of getting environmental variables
... make sense?

clarke: specify parameter would be to algorithm
... the video stream provides information for algorithm to use

duncan: how long to take the last segments, etc.

pablo: how does this relate to DASH?
... is this already part of it?

clarke: this can support DASH and the other new adaptive approaches

pablo: ok

igarashi: some questions
... sent a message to the mail list
... not sure about the detail of this proposal
... going to define some generic format like MPEG-DASH?

clarke: read your message
... some transcoding?

igarashi: converting of documents
... DASH has so-called manifest
... do you want to convert a manifest to another?

clarke: a manifest file is a possible part of the solutions
... MIME type is another solution
... I don't know Mark has more opinions

mark: this description is clear

clarke: will respond to your message and try to explain the detail

igarashi: another fundamental question
... adequate band width would be identified by whom?

clarke: JavaScript would be able to specify parameters, e.g., minimum bandwidth
... you implementation will be able to make final decision to use which information

mark: standardize our current practice is our target
... flash, silverlight, etc.
... in other work in related video, e.g., flash API

igarashi: ok
... that kind of example is useful for me

pablo: issue on synchronization?

clarke: interaction of use cases?

pablo: media should be also synchronized

clarke: agree
... any more questions/comments?

everybody: none

clarke: we want to discuss HTML5 LC comments as well

issue-35

<Clarke> issue 35: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Continuous_Streaming

issue-35?

<trackbot> ISSUE-35 -- Continuous Streaming -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/35

clarke: (explains the description)
... the queue is unlimited
... need for support of continuous streaming
... also standardize synchronization (as Pablo has just mentioned)
... how to synchronize segments?
... universal time code?
... comments?

igarashi: understood
... how to handle synchronization of video stream and audio stream? what if data blackout?
... without any black screen or silent audio, can we continue streaming?

clarke: question of multiple streams which need to be kept streaming?

kaz: question of different formats?

igarashi: even same formats/codecs have synchronization issue

clarke: @@@

pablo: requirement for synchronization of multiple streams

clarke: streams from different resources
... timing synchronization mechanism is needed

kaz: do we want to synchronization potion to issue-35? or create another issue?

<pcesar> issue35: we might want to take a look at Timesheets http://www.w3.org/TR/timesheets/

clarke: should be a separate issue
... issue-32 as well
... will reorganize them a bit and define a synchronization proposal

<scribe> ACTION: clarke to look at use cases and see if synchronization could be a stand-alone proposal [recorded in http://www.w3.org/2011/07/28-webtv-minutes.html#action01]

<trackbot> Created ACTION-57 - Look at use cases and see if synchronization could be a stand-alone proposal [on Clarke Stevens - due 2011-08-04].

pablo: mentions TImesheets spec

kaz: relationship between timesheets and timed text?

pablo: timed text is for caption, while timesheets is for synchronizing medias

igarashi: my question was not synchronization, but continuous streaming and seamless playback

clarke: ok

issue-36

<Clarke> issue 36: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Parental_Controls

issue-36?

<trackbot> ISSUE-36 -- Parental Controls -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/36

clarke: making metadata available for some kind of control

igarashi: is your idea just for UA to block some data based on the metadata?

clarke: if you want to make the data available (e.g., for JavaScript)
... this interface potentially expose the metadata to third parties
... the idea is bring the metadata outside UA, e.g., those third parties

igarashi: it's not the server side who knows about this kind of info (=parental control metadata)

clarke: will see the description has any assumption on UA

igarashi: ok

pablo: dynamic insertion as well?

clarke: if we need to add things to communicate with the server or the UA
... that should be found out
... would postpone the other use cases, and talk about HTML5 comments

HTML5 Bugs

mark: 4 bugs
... just wanted to review them

<Clarke> http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

<Clarke> http://www.w3.org/Bugs/Public/show_bug.cgi?id=13357

<Clarke> http://www.w3.org/Bugs/Public/show_bug.cgi?id=13358

<Clarke> http://www.w3.org/Bugs/Public/show_bug.cgi?id=13359

mark: the first one was post by Glenn Adams from Samsung

<Clarke> That's Glenn Adams from Samsung

mark: the other 3 were provided by Bob from CableLabs
... the key thing for our IG is whether to support parameters into media element
... questions?

pablo: completely agree this parameter is needed

clarke: what is the procedure for this discussion?

mark: the requirements should go to the bug system
... in addition, the whole IG should ensure

kaz: (explains the procedure; we need to check with the Web and TV IG co-Chairs as well)

clarke: any objection with 13333?

everybody: nope

RESOLUTION: all the MPTF participants agree to bug 13333

mark: next: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13357

igarashi: what is the use case?

mark: if their are multiple tracks (main and description) on multiple UAs, you would need to know
... maybe there could be another solution

igarashi: solution depends on use cases

mark: these control shows up on the UA interface
... user can select different kind of audio

igarashi: what kind of audio tracks are you thinking?
... main, description?

mark: currently, main and description

igarashi: those values are defined by ATSC?

mark: but HTML5 doesn't have mechanism for that

clarke: any objection to 13357?

evebody: none

RESOLUTION: unanimous agreement for 13357

clarke: will continue to review the other two comments by email

[ adjourned ]