- From: Raphaël Troncy <raphael.troncy@eurecom.fr>
- Date: Wed, 15 Jun 2011 15:09:40 +0200
- 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
below).
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.
Raphaël
-----------
[1]W3C
[1] http://www.w3.org/
Media Fragments Working Group Teleconference
15 Jun 2011
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-media-fragment/2011Jun/0010.html
See also: [3]IRC log
[3] http://www.w3.org/2011/06/15-mediafrag-irc
Attendees
Present
Yves, Jack, Davy, Chris, Silvia, Raphael, Erik, Philip, (irc)
Regrets
Thomas
Chair
Raphael, Erik
Scribe
raphael
Contents
* [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
ACTION:-)
1. ADMIN
PROPOSED to accept the minutes of the last week telecon:
[11]http://www.w3.org/2011/06/08-mediafrag-minutes.html
[11] http://www.w3.org/2011/06/08-mediafrag-minutes.html
<davy> +1
<erik> +1
+1
<jackjansen> +1
minutes accepted
<doublec> +1
2. SPEC MAINTENANCE
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>
[12]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/218
[12] 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>
[13]http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC001
8-UA
[13]
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
[14]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>
[15]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/221
[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
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>
[16]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/222
[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
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
[17]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>
[18]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/224
[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
[19]http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01
-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&
docstatus=cr-tr
[19]
http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=cr-tr
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
5. AOB
none
meeting adjourned
<scribe> ACTION: double to announce a link to a nightly implementing
part of the media fragment spec [recorded in
[20]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].
Summary of Action Items
[NEW] ACTION: davy to edit the spec again to switch back to "ID" for
the 4th dimension [recorded in
[21]http://www.w3.org/2011/06/15-mediafrag-minutes.html#action02]
[NEW] ACTION: davy to edit the specification and in particular
section 6 to reflect this entire discussion [recorded in
[22]http://www.w3.org/2011/06/15-mediafrag-minutes.html#action01]
[NEW] ACTION: double to announce a link to a nightly implementing
part of the media fragment spec [recorded in
[23]http://www.w3.org/2011/06/15-mediafrag-minutes.html#action03]
[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