W3C

Media Fragments Working Group Teleconference

11 May 2011

Agenda

See also: IRC log

Attendees

Present
Raphael, Chris_Double, Erik, Yves, foolip, Davy, Silvia, tomayac
Regrets
Jack
Chair
Erik
Scribe
Raphael

Contents


<trackbot> Date: 11 May 2011

<scribe> Scribe: Raphael

<scribe> Scribenick: raphael

<doublec> 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: 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> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/217

<davy> 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> 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> 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, 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 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, http://lists.w3.org/Archives/Public/public-media-fragment/2011May/0004.html
... what is the behaviour of a UA getting a 416 from a

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

<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 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 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 http://www.w3.org/2011/05/11-mediafrag-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2011/05/11 10:07:19 $