W3C home > Mailing lists > Public > public-media-fragment@w3.org > June 2011

minutes of 2011-06-15 teleconference

From: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Date: Wed, 15 Jun 2011 15:09:40 +0200
Message-ID: <4DF8AF14.6060807@eurecom.fr>
To: Media Fragment <public-media-fragment@w3.org>
Dear all,

The minutes of today's phone telecon are available for review at 
http://www.w3.org/2011/06/15-mediafrag-minutes.html (and in text format 

In a nutshell:
   - We resolve to switch back to name the fourth dimension for 
addressing media fragment #id= (instead of #chapter=)
   - We still aim at transitioning to CR next telecon. Davy has some 
edits to perform this week and I will prepare the diff documents and 
disposition of comments
   - Yves is in charge to start a new thread regarding the status of the 
section 5.2 and whether this part (considered as exploratory) should be 
put in a separate W3C Note or be kept in the main specification that 
will go Recommendation.


       [1] http://www.w3.org/
              Media Fragments Working Group Teleconference
15 Jun 2011
    See also: [3]IRC log
       [3] http://www.w3.org/2011/06/15-mediafrag-irc
           Yves, Jack, Davy, Chris, Silvia, Raphael, Erik, Philip, (irc)
           Raphael, Erik
      * [4]Topics
          1. [5]1. ADMIN
          2. [6]2. SPEC MAINTENANCE
          3. [7]3. Name of the 4th dimension
          4. [8]4. CR transitioning
          5. [9]5. AOB
      * [10]Summary of Action Items

    <trackbot> Date: 15 June 2011

    <doublec> I get 'dispatch code is not valid'

    <doublec> when trying to enter the conference code

    <doublec> yes

    <silvia> hmmÖ I am still at work and about to go homeÖ am I needed
    in the meeting?

    Chris announcing some nightlies to see part of media fragments in


    PROPOSED to accept the minutes of the last week telecon:


      [11] http://www.w3.org/2011/06/08-mediafrag-minutes.html

    <davy> +1

    <erik> +1


    <jackjansen> +1

    minutes accepted

    <doublec> +1



    <trackbot> ACTION-218 -- Jack Jansen to carrefully review the
    changes made by Davy that will most likely be all over the palce --
    due 2011-04-20 -- OPEN


      [12] http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/218

    Jack: I'd like that people go through this list and address these
    ... going through my comments, the first one is actually about
    section 6.1.1
    ... it is indeed a typo, e should be > 0
    ... should we allow empty images or empty video files ?

    Davy: no, no empty images, so we are right to write w>0 and h>0
    ... for consistency, we do the same for temporal, to e>0 (strictly

    Jack: harmonize the text, between play from x to y OR play from x
    until y ... and also specifiy if the last frame should or should not
    be played
    ... this is an open interval so the last frame shouldn't be played

    Raphael: we should even have a test case that check this

    Jack: this is important if we start combining media fragments
    ... we use width as opposed to right so it is clear which pixels are
    actually displayed
    ... this is clear, we can ignore this point
    ... #t=a, is illegal

    Davy: yes per the ABNF and per the test case

    Raphael: we should put it in the section 6.2.2 as a typical example
    of error case



    Jack: problem with SMPTE time code adressing: are we always
    guaranteed to have frame accuracy

    <foolip> I don't think the spec is anywhere near CR, it has no
    browser implementations yet. (I also don't know why the spec status
    is important.)

    <foolip> I have no opinion on the name, id is fine by me.

    Philip, CR does not mean implementations ... PR mean implementations

    <Yves> foolip, CR is a call for implementations, so it's normal not
    to have implementation at that stage (and the end result might be
    going back to LC again)

    <foolip> OK, no opinion on spec status

    <Yves> in any case, we know that most implementers are aware of the
    status of the edcopy :)

    Jack: perhaps we could let it explicitly as "implementation to be
    ... if you do spmte addressing on smpte encoded media has a well
    defined behavior
    ... but if you do smpte addressing on non smpte-encoded media, then
    it is explicly undefined and we wait for implementation experience

    <doublec> We have no plans to implement smpte timecods

    Raphael: I think foolip does not plan to implement smpte addressing,
    correct foolip ?

    <foolip> raphael, correct

    Jack: that is fine, this not for browsers, this is more for editing

    Silvia: gstreamer has a plan to implement media fragments with smpte
    time codes addressing for live streaming!

    <silvia> flumotion

    Davy: WebTV IG has also interest in frame accuracy

    <Yves> but does editing programs needs identifying such timepoints
    using URIs ?

    <silvia> Thomas van der Stichele from Fluendo

    Davy: we should keep an eye on this group

    Raphael: I will check if Thomas is subscribed to this mailing list

    <Yves> ok, thanks Jack, the annotations is indeed a use case

    Jack: the annotation use case is important, not only for playback,
    in an editing program that would use a URI to identify a frame

    Davy: no we don't have test cases yet for a<s and b<s and various
    combinations (because smpte timecodes don't have to be zero-based)
    ... we removed them for npt since these resources cannot start with
    0, but we should add them back for smpte

    Jack: undefined for non contiguous smpte timecodes
    ... we need much more implementation experience

    Raphael: I'm in favor of saying explicitly it is *undefined*

    +1 from Jack and Davy

    <silvia> +1

    Raphael: going through the problem of track names discovery
    ... and errors on the track dimension

    Jack: what's happen with #track=foo&t=10,40 ?
    ... and track foo starts at t=25
    ... an implementation will play this track from 25 to 40 ?
    ... or play all the tracks from 10 to 25 and start to play from 25
    to 40 the track foo ?

    Silvia: no, you just select the track, and return the sub part you
    ... I wouldn't write anything about this, this is a general problem
    ... this is a corner case
    ... again an implementation quality issue

    Jack: again, then I would be in favor of saying explicitly undefined
    ... if a track does not exist for the whole duration of the media,
    then what is happened is undefined
    ... a forthcoming WG could fix it
    ... 6.3.5: we should explicitly state what happens if you apply a
    chapter MF to a media format that doesn't support chaptering?

    Davy: we have a test case for that

    <Yves> yes, same defaulting behaviour as 'not found'

    Davy: same behavior that the media format supporting chapters but
    the chapter is not found

    close ACTION-217

    <trackbot> ACTION-217 Edit the specification for precising what is
    the user experience when there is an invalid time range closed

    ACTIO: davy to edit the specification and in particular section 6 to
    reflect this entire discussion

    <scribe> ACTION: davy to edit the specification and in particular
    section 6 to reflect this entire discussion [recorded in

    <trackbot> Created ACTION-225 - Edit the specification and in
    particular section 6 to reflect this entire discussion [on Davy Van
    Deursen - due 2011-06-22].


    <trackbot> ACTION-221 -- Davy Van Deursen to fix the #t=10, in
    Section 4.2.1 which is invalid -- due 2011-06-15 -- OPEN


      [15] http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/221

    close ACTION-221

    <trackbot> ACTION-221 Fix the #t=10, in Section 4.2.1 which is
    invalid closed


    <trackbot> ACTION-222 -- Davy Van Deursen to adapt Section 5.2.3 so
    that the server can also send back the mapping in terms of byte
    ranges -- due 2011-06-15 -- OPEN


      [16] http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/222

    close ACTION-222

    <trackbot> ACTION-222 Adapt Section 5.2.3 so that the server can
    also send back the mapping in terms of byte ranges closed

3. Name of the 4th dimension

    <jackjansen> I fully agree with Philip

    <jackjansen> I disagree with "cue", the other ones are fine. "Cue"
    is a point, not an interval;

    Raphael: chapter might not be a good dimension name for possible
    confusion with the chapter track

    <jackjansen> lol

    Silvia: segment?

    Raphael: id

    <jackjansen> range? area? part?

    <doublec> bookmark?

    <jackjansen> -bookmark: it's a point

    <doublec> what do the users suggest as an alternative?

    Silvia: I'm worried about the users, not the programmer

    Jack: initally we talked about id but said it replaced all
    ... now we restrict it to only time ranges
    ... and renamed it chapter

    <Yves> shortcut?

    Jack: so if this is just a temporal range, chapter is good

    Silvia: chapter in the context of HTML5 is made for navigational

    Jack: I'm in +-0

    Raphael: I like "id" because it is general and can extended in
    version 2

    <davy> +1

    Erik: id I prefer

    <foolip> perhaps our problem is that the best solution would be
    #nameofthingtoseekto, just like for HTML, but that unfortunately
    conflicts with something else we've made up :)

    <silvia> #nameofthingtorestrictto

    Yves: id also conflicts with HTML

    <foolip> silvia, so you no longer think users should be able to seek
    outside of the given fragment? ;)

    Jack: I disagree, id refers to a continuous section of a structured
    ... and this is what we mean

    Yves: id means point

    <doublec> fragment?

    Jack: no, a node that points to a subsection

    <doublec> :)

    Raphael: propose to switch back to ID

    <doublec> I just noticed everyone was calling it a fragment

    <jackjansen> +0

    <silvia> +.5

    <doublec> +1 to id

    +1 for ID

    <davy> +1 for id

    <erik> +1 to id

    <Yves> ~0 for id

    <jackjansen> ~0? you mean 0xffffffff?

    <Yves> yep!

    <jackjansen> That's -1 to me....

    <Yves> now use the right type, signed or unsigned...

    <scribe> ACTION: davy to edit the spec again to switch back to "ID"
    for the 4th dimension [recorded in

    <trackbot> Created ACTION-226 - Edit the spec again to switch back
    to "ID" for the 4th dimension [on Davy Van Deursen - due


    <trackbot> ACTION-224 -- RaphaŽl Troncy to send a reply to the 4
    commenters -- due 2011-06-15 -- OPEN


      [18] http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/224

4. CR transitioning

    Yves: diff versions need to be prepared
    ... just run htmldiff between the two LC and the CR version

    <Yves> see


    Yves: the disposition of comments ?
    ... create an HTML page for this
    ... the comments between 1st LC, 2nd LC and CR
    ... I'm wondering if the whole section 5.2 should not be put aside
    in a different document with a note status ?

    Jack: do we want a note or an extension to be a spec later on

    Yves: a note would be better, it could be picked up by WG later on
    ... there are multiple ways of doing the same thing and I'm not sure
    it should be in the spec

    Jack: it is a painful decision to make because we have devoted a lot
    of time in it
    ... but I think I agree with you

    Silvia: I don't think this is fine. I believe implementers will need
    this part and consistently used

    <silvia> it's about getting interoperable implementations

    Jack: look at the audience of this document: end users, web
    designers, people doing implementations

    Silvia: no, I disagree, we are targetting the URI spec readers

    <Yves> rfc3986 is different from rfc2616

    Raphael: I agree with Silvia, and I don't think we should throw away
    this part

    Jack: this is clear that this part is nice for browser vendors, but
    it is not interesting for other readers

    Raphael: I don't think that our spec is that *long* that we should
    bother with part targetted at a different audience

    <Yves> I will take that to email

    <silvia> a specification is there to create interoperable

    <silvia> it's not a communication tool for users - they can get
    their information from other websites that have created readable
    subparts from the specification

    <erik> +1 to Raphael & Silvia ... if some are not interested in some
    parts, you just don't read it ... browser vendors are main players
    that will make this spec work (I think)

    Rapahel: I will prepare the diff files and the disposition of

    Yves: I will follow up this discussion by email + indicating the
    status of HTTP Bis and request for implementations from Marc

5. AOB


    meeting adjourned

    <scribe> ACTION: double to announce a link to a nightly implementing
    part of the media fragment spec [recorded in

    <trackbot> Created ACTION-227 - Announce a link to a nightly
    implementing part of the media fragment spec [on Chris Double - due

Summary of Action Items

    [NEW] ACTION: davy to edit the spec again to switch back to "ID" for
    the 4th dimension [recorded in
    [NEW] ACTION: davy to edit the specification and in particular
    section 6 to reflect this entire discussion [recorded in
    [NEW] ACTION: double to announce a link to a nightly implementing
    part of the media fragment spec [recorded in

    [End of minutes]

RaphaŽl Troncy
EURECOM, Multimedia Communications Department
2229, route des CrÍtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/
Received on Wednesday, 15 June 2011 13:10:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:46 UTC