W3C home > Mailing lists > Public > public-web-and-tv@w3.org > February 2012

[MEDIA_PIPELINE_TF] minutes - 9 February 2012

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 10 Feb 2012 02:46:46 +0900
Message-ID: <4F340686.6010703@w3.org>
To: public-web-and-tv@w3.org
available at:

also as text below.

Thanks for taking these minutes, Duncan!



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

                                - DRAFT -

                     Media Pipeline Task Force call

09 Feb 2012



    See also: [3]IRC log

       [3] http://www.w3.org/2012/02/09-webtv-irc


           Clarke, Kaz, John, Giuseppe, Duncan, Franck, Russell,
           Philipp, Mark, Jason, Juhani, Kilroy




      * [4]Topics
          1. [5]content protection
          2. [6]bug 12544
          3. [7]model 3 architecture
      * [8]Summary of Action Items

    <Clarke> Hi

    <scribe> Scribe: duncanr

    <kaz> bug 12544

    <kaz> scribe: duncanr

    <kaz> scribenick: duncanr

    <Clarke> Agenda:


    Clarke: goes through Agenda
    ... front page of MPTF site has a dashboard

    <kaz> [10]MPTF site

      [10] http://www.w3.org/2011/webtv/wiki/MPTF

    Clarke: take a look at it when given chance and provide feeback

content protection

    Clarke: MarkW wants to postopone content protection propsal
    ... focus next week or the week after for discussion on that

    Jason: what vendors are being considered for this proposal?

    Clarke: let me know if there are other vendors to be included in

bug 12544

    Clarke: before we disuss model 3 lets discuss bug 12544

    <mav> [11]https://www.w3.org/Bugs/Public/show_bug.cgi?id=12544

      [11] https://www.w3.org/Bugs/Public/show_bug.cgi?id=12544

    MarkV: explains bug summary

    <mav> [12]https://www.w3.org/Bugs/Public/show_bug.cgi?id=13357

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

    MarkV: related bug: 13357
    ... current audio and video discriptions assume that they are sent
    ... this is not always the case

    <mav> I've tried to map the most useful DASH role combinations to
    the defined HTML

    <mav> values. Hopefully that's good enough for most purposes. If
    there are specific

    <mav> use cases that this doesn't handle, please file separate bugs
    (I don't mind if

    <mav> they are handled as LC1 bugs).

    <mav> If there are other specifications that define specific roles
    that should be

    <mav> mapped here, please file separate bugs with links to the
    relevant specs (I

    <mav> don't mind if they are handled as LC1 bugs either).

    MarkV: if there are relevant bugs regarding to other external specs
    then they will be considered as LC1
    ... question to the group, are there any such bugs?
    ... look at whatwg spec



    MarkV: I would encourage people to discuss issue

    Kilroy: thanks for heads up

    Clarke: will record this bug on front page of MPTF site
    ... next topic is model 3 architecture

model 3 architecture

    Clarke: has a couple of questions of chrome architecture
    ... one of the issues from last week was what html would look like
    for video element that uses script to parse manifest
    ... looking at chromium it looks like regular video element with
    some js that gets media chunks and adds a few listeners
    ... do we want the video element to specify this?

    Jason: generally agrees

    Clarke: will write something on wiki

    Clarke explains APIs

    Clarke: anybody have any thought on pros and cons?

    Kilroy: there's some issues around the simple append.
    ... assumes you are just appending one segment
    ... there may be sperate appending for different media types
    ... issue of time alignment too
    ... in best case they are nicely aligned, other times they could
    ... the script needs to know that
    ... segment decoded needs to be able to calculate common time bases
    ... complexity of accurate splicing

    scribe missed question

    <kaz> jason: @@@

    Clarke: sounds like there are some things that need to be fleshed

    Kilroy: the whatwg and chrome proposals both have same fundamental
    ... the DASH spec has flags that describes media.

    <kaz> jason: @@2

    scribe couldn't hear question

    Kilroy: two profiles for MPEG-TS
    ... it is necissary to know capability of decoder
    ... can in handle everything in manifest file?
    ... mpeg2-ts are self-initialising
    ... headers are repeated
    ... iso files and others have header information that is required to
    start decoding
    ... you might have to start by appending an initialise segment
    ... for live encoding you might have to initialise for each segment
    ... but on the other hand these headers might be inband and won't
    need intialising
    ... does that script retain the intialisation or does the player do

    Clarke: the MIME type is not sufficient to know about this

    Kilroy: no it only tells you about a container, codec but not on
    detailed profile
    ... impossible to characterise all paramters.

    Clarke: limit those MIME types to most popular collections?

    Kilroy: MIME type list would be huge to specify everything
    ... do you allow switching between HD and SD? how is adaptive coding
    and scaling done?

    Clarke: raise these issues in the wiki
    ... so discussion can take place around them
    ... please can Kilroy/ anybody do this
    ... any question?

    Jason: do we need a way of querying the video tag?

    Kilroy: yes, we need to know what the decoder is capable of

    Clarke: any more questions?
    ... as you discover issues raise them with the group

    <kaz> [14]Chromium proposal


    Clarke: we will compile them weekly and discuss them as we go on
    ... end of meeting

    <kaz> [ adjourned ]

Summary of Action Items

    [End of minutes]

     Minutes formatted by David Booth's [15]scribe.perl version 1.136
     ([16]CVS log)
     $Date: 2012/02/09 17:38:06 $

      [15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [16] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 9 February 2012 17:47:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:06 UTC