W3C home > Mailing lists > Public > public-web-and-tv@w3.org > July 2011

[MEDIA_PIPELINE_TF] minutes - 28 July 2011

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 29 Jul 2011 03:36:25 +0900
Message-ID: <4E31AC29.5070005@w3.org>
To: public-web-and-tv@w3.org
available at:

also as text below.



       [1] http://www.w3.org/

                                - DRAFT -

                   Media Pipeline Task Force Teleconf

28 Jul 2011


       [2] http://lists.w3.org/Archives/Public/public-web-and-tv/2011Jul/0057.html

    See also: [3]IRC log

       [3] http://www.w3.org/2011/07/28-webtv-irc


           Duncan, Kazuyuki, Jerry, Richard, Pablo, Gondo, Igarashi




      * [4]Topics
          1. [5]issue-34
          2. [6]issue-35
          3. [7]issue-36
          4. [8]HTML5 Bugs
      * [9]Summary of Action Items


    <Clarke> issue-34:

      [10] 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:

      [11] http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Continuous_Streaming


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

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

      [12] 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

    clarke: question of multiple streams which need to be kept

    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

      [13] 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

    <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:

      [15] http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Parental_Controls


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

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

      [16] 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

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

    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

HTML5 Bugs

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

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

      [17] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

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

      [18] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13357

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

      [19] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13358

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

      [20] 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: [21]http://www.w3.org/Bugs/Public/show_bug.cgi?id=13357

      [21] 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 ]

Summary of Action Items

    [NEW] ACTION: clarke to look at use cases and see if synchronization
    could be a stand-alone proposal [recorded in

    [End of minutes]
Received on Thursday, 28 July 2011 18:35:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:06 UTC