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

[MEDIA_PIPELINE_TF] minutes - 2 February 2012

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Fri, 03 Feb 2012 02:17:33 +0900
Message-ID: <4F2AC52D.2020708@w3.org>
To: public-web-and-tv@w3.org
available at:
http://www.w3.org/2012/02/02-webtv-minutes.html

also as text below.

Thank you very much for taking these minutes, Mark Vickers!

Kazuyuki

---
    [1]W3C

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

                                - DRAFT -

                Web and TV Interest Group Teleconference

02 Feb 2012

    [2]Agenda

       [2] 
http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_2nd_February_2012#Agenda

    See also: [3]IRC log

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

Attendees

    Present
           Kazuyuki, Mark_Vickers, Clarke, glenn, Bryan_Sullivan,
           Duncan, Jason, Franck, John_Simmons, Russell, Philipp,
           Bob_Lund, Kilroy_Hughes

    Regrets
    Chair
           clarke

    Scribe
           mav

Contents

      * [4]Topics
          1. [5]scribe list
          2. [6]Reorganizing site
          3. [7]Scheduling of work on content protection
          4. [8]Model 3 architecture discussion
      * [9]Summary of Action Items
      _________________________________________________________

scribe list

    <kaz> [10]scribe list

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

    See Scribe Schedule on wiki

Reorganizing site

    clarke: will take first shot at organizing site. Will take
    suggestions.

Scheduling of work on content protection

    clarke: Current plan: 1st adaptive bitrate, 2nd: content protection

    jason: content protection bigger issue for content industry, so
    don't put it off too long

    philipp: what was sent from IG to HTML WG on content protection to
    date?

    [11]http://www.w3.org/2011/webtv/wiki/MPTF/Netflix_Content_Protectio
    n

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

    clarke: sent along netflix proposal, but not reviewed by group

    <bryan> +1 to continuing work on both in parallel - I will seek
    internal input to provide as feedback

    mark_watson: OK with adaptive & content protection in parallel.
    haven't gotten feedback from group on netflix proposal yet. would
    like to get feedback.

    clarke: Propose content protection for agenda next week.

Model 3 architecture discussion

    clarke: Ran into issues with ladder diagram.
    ... Not clear how model 3 would work, e.g. new MIME type or not.
    Also not clear how processing would pass to script

    <glenn> can't hear markw over background noise on his end

    mark_watson: Look at Chrome proposal on Media Source Extension
    proposal
    ... script controls content feeding

    <glenn> link to "Media Source Extension proposal"??

    bob_lund: Problem selecting among alternative media.

    mark_watson: Current Chrome model is all decisions in script, not
    media element

    <kaz> [12]ADR Error Codes

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

    jason: The use case of script able to pass segments is agnostic.

    duncan: Problem with both approaches - more script control requires
    more query to engine.

    mark_watson: That can mostly be handled by canPlayType
    ... usage of codec parameters can handle most cases, there may be
    some corner cases, e.g. limited support for interlace

    clarke: duncan's proposal has 3 APIs: appendVideo,
    currentSegmentDownload [scribe: what was 3rd?]

    <franck>
    [13]http://www.w3.org/2011/webtv/wiki/MPTF/HTML_adaptive_calls

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

    mark_watson: need to generalize appendVideo API to allow placement
    other than next in sequence

    jason: what about a sliding window in live or simulcast? how is
    anchor maintained?

    mark_watson: Not worked out live fully, but need ability to place
    segments in time line.

    clarke: Another example is placing ads within a program

    bob: Agree key is to use timeline in media.

    Kilroy: There are difficulties with splicing, e.g. if lengths of
    media segments don't line up. API to support such splicing can get
    complex.
    ... Concatenating use case OK, splicing gets more complex.

    jason: HLS use case is usually simple concatenation.

    kilroy: Script needs to know if streaming engine can handle splicing
    issues like padding for iframes.
    ... API needs to differentiate between concatenating vs. complex
    splicing.
    ... Segment formats can have constraints that allow for simple
    concatenation.
    ... Work on this going on in DASH and other groups. Would rather
    present consensus than own opinion.

    clarke: Has DASH resolved this?

    kilroy: DASH work on this still in progress, interacting with
    several API groups and the several media formats: h264, DASH, etc.

    clarke: How do we make a proposal in this area?

    mav: Shall we take adaptive & content protection off of HTML5 LC
    bugs from WebTV IG?
    ... Suggest Mark Watson decide on whether to withdraw Netflix
    proposal from LC bug

    clarke: Other agenda items?

    bob_lund: bug 13359 discussion

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

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

    bob: I made a proposal submitted for passing data from media stream
    to script. There's been some push back as complex. There's been some
    suggestions for simplification.
    ... I think we'll get something, but not clear what it will be.

    bob: I encourage others to comment.

    clarke: adjourn

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/02 17:17:35 $

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

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