See also: IRC log
<trackbot> Date: 11 May 2011
<scribe> Scribe: Raphael
<scribe> Scribenick: raphael
<doublec> https://bugzilla.mozilla.org/show_bug.cgi?id=648595
<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
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
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! :-)