minutes of 2011-05-11 teleconference

Dear all,

The minutes of last Wednesday's phone telecon are available for review 
at http://www.w3.org/2011/05/11-mediafrag-minutes.html (and in text 
format below).

We adopted a number of RESOLUTIONS, in particular:
   - Rename the #id dimension into #chapter and restrict the scope of 
this dimension as a convenient way of specifying a temporal fragment 
only. Consequently, #id can also be combined with other dimensions and 
the rules are the same that when the #t dimension is combined.
   - We consider that the #track dimension can only be applied locally, 
as #xywh, so the full resource is always requested

Jack, if you object to one of these resolutions, please let us know.

Outstanding new ACTIONS:
* ACTION-219: Davy to update the specification to reflect the changes 
regarding the new "chapter" dimension
* ACTION-220: Raphael to change the specification to reflect that #track 
is local
Best regards.

   Raphaël

----------
    [1]W3C
       [1] http://www.w3.org/
              Media Fragments Working Group Teleconference
11 May 2011
    [2]Agenda
       [2] 
http://lists.w3.org/Archives/Public/public-media-fragment/2011May/0054.html
    See also: [3]IRC log
       [3] http://www.w3.org/2011/05/11-mediafrag-irc
Attendees
    Present
           Raphael, Chris_Double, Erik, Yves, foolip, Davy, Silvia,
           tomayac
    Regrets
           Jack
    Chair
           Erik
    Scribe
           Raphael
Contents
      * [4]Topics
          1. [5]1. Admin
          2. [6]2. TEST CASES
          3. [7]3. AOB
      * [8]Summary of Action Items
      _________________________________________________________

    <trackbot> Date: 11 May 2011

    <scribe> Scribe: Raphael

    <scribe> Scribenick: raphael

    <doublec> [9]https://bugzilla.mozilla.org/show_bug.cgi?id=648595

       [9] https://bugzilla.mozilla.org/show_bug.cgi?id=648595

1. Admin

    <doublec> Zakim: mute me

    PROPOSED to accept the minutes of the last week telecon:
    [10]http://www.w3.org/2011/04/13-mediafrag-minutes.html

      [10] http://www.w3.org/2011/04/13-mediafrag-minutes.html

    <davy> +1

    +1

    <erik> +1

    <Yves> +1

    minutes accepted

2. TEST CASES

    action-217?

    <trackbot> ACTION-217 -- Davy Van Deursen to edit the specification
    for precising what is the user experience when there is an invalid
    time range -- due 2011-04-20 -- OPEN

    <trackbot>
    [11]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/217

      [11] http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/217

    <davy>
    [12]http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spe
    c/#media-fragment-semantics

      [12] 
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#media-fragment-semantics

    close ACTION-217

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

    Davy: section updated in the specification
    ... this section has now 3 sub-sections: valid media fragments with
    border cases, invalid media fragments (invalidity detectable looking
    at the URI), invalid media fragments but information from the source
    media are required to detect them
    ... I'm happy to receive comments
    ... Jack has an action to review it

    ACTIOn-218?

    <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

    <trackbot>
    [13]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/218

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

    Raphael: I will send a reminder to Jack to complete this action
    based on Davy's addition

    Erik: I like Davy's structure, so if nobody objects, then we go for
    it

    ACTION-146?

    <trackbot> ACTION-146 -- Jack Jansen to identify any missing test
    cases for temporal fragments -- due 2010-03-03 -- OPEN

    <trackbot>
    [14]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/146

      [14] http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/146

    close action-146

    <trackbot> ACTION-146 Identify any missing test cases for temporal
    fragments closed

    Erik: this is not anymore relevant as we do not use Corrib now
    ... since last week, there are new threads of discussion

    Davy: Test case for named and temporal fragment combination,
    [15]http://lists.w3.org/Archives/Public/public-media-fragment/2011Ma
    y/0001.html

      [15] 
http://lists.w3.org/Archives/Public/public-media-fragment/2011May/0001.html

    <davy> #id=song1&t=10

    Davy: what is the behavior of the UA when facing the fragment
    #id=song1&t=10?
    ... id cannot be combined with another dimension

    Yves: since you don't know the intent of the author, the best is to
    ignore the whole fragment

    Davy: I agree with that

    Philip: I think that the behavior should be the same as if someone
    does not implement the id dimension at all
    ... since this is what Opera will do in a first place
    ... so in this case, it will be treated as #t=10

    <Yves> well, not supporting id might still have a rule that says
    that there is a conflict in the time dimension

    Silvia: I think the id dimension should also be ignored, so that
    xywh, t and track will be interpreted

    <silvia> it's a kind of "meta"-dimension, which should fall away if
    details on any of the other dimensions are provided

    Philip: another suggestion will be that the other dimensions
    override the id dimension if they are combined

    <silvia> same effect :-)

    <foolip> not exactly

    <davy> #id=song&t=10 -> #t=20&t=10 -> #t=10

    <foolip> but close enough, doesn't matter much

    <davy> is that what you mean philip?

    <foolip> davy, I mean that if #id=song is expanded to
    #t=10&track=audio0, then #id=song&t=40 => #track=audio0&t=40

    <Yves> real question is... is 'id' really needed

    <foolip> indeed, I've suggested to drop it earlier

    Davy: I have written a number of examples that use media fragments,
    but none of them really needed the id dimension

    Raphael: does this group think we should drop the id dimension?

    Yves: id is mainly here for chapter names ... this still might be
    interested for media annotations people

    Silvia: I think for chapters, it can still be useful, we have use
    cases for this
    ... but there is very little media files that expose chapter names
    out there

    <Yves> rename id to chapter ? (ie: reduce its scope)

    Silvia: though, it might change with an increasing support of VTT
    ... so we could restrict id to a time fragment

    <foolip> perhaps we should just put this on the bottom of the prio
    list and decide later?

    <silvia> I support this :-)

    <foolip> no opinion on test cases

    <doublec> reserve id for future use and say it is ignored for now if
    it is included in the fragment?

    <silvia> we can still decide on how such a url should be resolved
    though

    <foolip> sounds good to me

    Raphael: following Silvia's suggestion, we restrict id to a time
    fragment
    ... id combined with other dimensions has the same behavior of #t
    combined with other dimensions

    <silvia> do you want to also rename it to "chapter" to make that
    clearer and leave "id" for future use?

    Raphael: if #id and #t are used together, this is the same behavior
    as if we have #t=10,t=20 for example

    <Yves> chapter makes more sense than id

    <davy> +1

    Raphael: I'm for renaming id to chapter

    <doublec> I prefer chapter

    <foolip> +-0

    <erik> +1

    <silvia> +1

    RESOLUTION: rename the id dimension into a chapter dimension
    ... the new 'chapter' dimension is just a convenient way of
    addressing a temporal fragment
    ... chapter dimension CAN be used in conjunction with other
    dimensions as the temporal one

    <scribe> ACTION: Davy to update the specification to reflect those
    changes [recorded in
    [16]http://www.w3.org/2011/05/11-mediafrag-minutes.html#action01]

    <trackbot> Created ACTION-219 - Update the specification to reflect
    those changes [on Davy Van Deursen - due 2011-05-18].

    Davy: Behaviour of Smart UAs vs. UAs that need server help in error
    cases,
    [17]http://lists.w3.org/Archives/Public/public-media-fragment/2011Ma
    y/0004.html
    ... what is the behaviour of a UA getting a 416 from a

      [17] 
http://lists.w3.org/Archives/Public/public-media-fragment/2011May/0004.html

    Media Fragments-enabled server?

    <Yves> it's a bad idea to send both ranges request

    Davy: it is not possible to send a byte ranges request and time
    range request

    Raphael: why the behavior should be different if the UA sent a byte
    range request or a time range request in a first place?

    Davy: the UA does not necessarily know the duration of the media

    <silvia> [18]http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
    <- says that the response SHOULD include a Content-Range
    entity-header field specifying the current length of the selected
    resource

      [18] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

    <davy> but what about non-existing tracks?

    Davy: should the server always send back the list of tracks
    available?

    <silvia> the UA should not rely on functionality of an "intelligent"
    server

    <Yves> sending back track list is not really giving hints on the
    length

    Davy: if we are just requesting a track range, and that track does
    not exist, currently we send back a 416
    ... maybe we should just not allow to request track range

    <silvia> ?

    Silvia: track are byte ranges in essence (not time ranges)
    ... it is up to the UA to resolve the track, in the worst case, the
    full resource will be requested
    ... this makes sense in HTML5, since it is generally impossible to
    guess what will be the byte ranges to request
    ... we really really need "track" in the a11y TF of HTML5

    Davy: our server supports the track keyword and the Range header ...
    but we have no example
    ... this is difficult to see use cases where you want just one track
    and difficult to implement

    Silvia: I see use cases, but no way of implementing them
    ... I think that for #xywh and #track, the full ressource should be
    requested and the dimension will be applied locally

    Davy: I agree with that, but currently, this is NOT what the spec is
    specifying

    Silvia: let's assume that a UA has a way to do the mapping between a
    track and byte ranges ... this would be like for the time dimension

    Raphael: 2 options on the table
    ... 1/ #track can only be applied locally, as #xywh, so the full
    resource is requested ... we NEED to remove text from the spec
    ... 2/ we leave the spec as it is, and track can be a keyword in the
    Range header issued by the UA, the server does a mapping between a
    track range request and byte range request ... we NEED to specify
    what the behavior is in case of 416

    Erik: codecs are interleaved, so you will end up in many many byte
    ranges in case of option 2, so for me, option 1 is preferrable

    Philip: I don't have a strong opinion, but I prefer the local option
    since I will not implement the new Range header other than byte
    range request

    <Yves> local option for tracks is the only one making sense

    Thomas: option 1 is also for me the most sensible one

    Raphael: +1 for option 1

    <davy> +1

    <erik> +1 for option 1

    <foolip> +1

    <tomayac> +1 for option 1

    <doublec> +1 for option 1

    RESOLUTION: #track can only be applied locally, as #xywh, so the
    full resource is requested

    <foolip> we're here

    <scribe> ACTION: troncy to change the specification accordingly to
    reflect that #track is local [recorded in
    [19]http://www.w3.org/2011/05/11-mediafrag-minutes.html#action02]

    <trackbot> Created ACTION-220 - Change the specification accordingly
    to reflect that #track is local [on Raphaël Troncy - due
    2011-05-18].

    <foolip> what's happening?

    Erik: I suggest we adjourn the meeting
    ... and I want to thank all for the great discussions
    ... we have 4 more threads to discuss next week

    meeting adjourned?

    <Yves> bye

3. AOB

    no

    meeting adjourned

    Really really pleased to have today's discussion and yes, for the
    trimming of the spec :-)

    <doublec> thanks silvia, glad to take part finally :)

    <silvia> doublec: your experience will shape how everyone else will
    implement it, so it's great you're helping fix the spec, too

    <silvia> yay for innovation! :-)

Summary of Action Items

    [NEW] ACTION: Davy to update the specification to reflect those
    changes [recorded in
    [20]http://www.w3.org/2011/05/11-mediafrag-minutes.html#action01]
    [NEW] ACTION: troncy to change the specification accordingly to
    reflect that #track is local [recorded in
    [21]http://www.w3.org/2011/05/11-mediafrag-minutes.html#action02]

    [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 Saturday, 14 May 2011 13:55:02 UTC