See also: IRC log
<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
<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
<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
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 ]