See also: IRC log
<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
... 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
... is this already part of it?
clarke: this can support DASH and the other new adaptive approaches
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
... 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
... adequate band width would be identified by whom?
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
... that kind of example is useful for me
pablo: issue on synchronization?
clarke: interaction of use cases?
pablo: media should be also synchronized
... any more questions/comments?
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
<trackbot> ISSUE-35 -- Continuous Streaming -- raised
clarke: (explains the
... 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?
... 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
pablo: requirement for synchronization of multiple streams
clarke: streams from different
... 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-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> issue 36: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Parental_Controls
<trackbot> ISSUE-36 -- Parental Controls -- raised
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
... 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
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
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
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?
RESOLUTION: all the MPTF participants agree to bug 13333
igarashi: what is the use case?
mark: if their are multiple
tracks (main and description) on multiple UAs, you would need
... 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?
RESOLUTION: unanimous agreement for 13357
clarke: will continue to review the other two comments by email
[ adjourned ]