See also: IRC log
<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 ACTION:-)
PROPOSED to accept the minutes of the last week telecon:
http://www.w3.org/2011/06/08-mediafrag-minutes.html
<davy> +1
<erik> +1
+1
<jackjansen> +1
minutes accepted
<doublec> +1
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
Jack: I'd like that people go
through this list and address these comments
... 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 greater)
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
<davy> http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0018-UA
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 defined"
... 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 programs
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 have
... 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 http://www.w3.org/2011/06/15-mediafrag-minutes.html#action01]
<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].
ACTION-221?
<trackbot> ACTION-221 -- Davy Van Deursen to fix the #t=10, in Section 4.2.1 which is invalid -- due 2011-06-15 -- OPEN
<trackbot> 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
ACTION-222?
<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
<trackbot> 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
<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 dimensions
... 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 purpose
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 document
... 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 http://www.w3.org/2011/06/15-mediafrag-minutes.html#action02]
<trackbot> Created ACTION-226 - Edit the spec again to switch back to "ID" for the 4th dimension [on Davy Van Deursen - due 2011-06-22].
ACTION-224?
<trackbot> ACTION-224 -- Raphaël Troncy to send a reply to the 4 commenters -- due 2011-06-15 -- OPEN
<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/224
Yves: diff versions need to be
prepared
... just run htmldiff between the two LC and the CR version
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 implementations
<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 comments
Yves: I will follow up this discussion by email + indicating the status of HTTP Bis and request for implementations from Marc Nottingham
none
meeting adjourned
<scribe> ACTION: double to announce a link to a nightly implementing part of the media fragment spec [recorded in http://www.w3.org/2011/06/15-mediafrag-minutes.html#action03]
<trackbot> Created ACTION-227 - Announce a link to a nightly implementing part of the media fragment spec [on Chris Double - due 2011-06-22].