See also: IRC log
<trackbot> Date: 13 April 2011
PROPOSED to accept the minutes of the last week telecon, http://www.w3.org/2011/04/06-mediafrag-minutes.html ?
<foolip> +1
+1
<davy> +1
minutes accepted
<scribe> Scribe: raphael
<scribe> Scribenick: raphael
TPAC 2011, http://www.w3.org/2011/11/TPAC/
Raphael: do you think we should meet?
Jack: hard to say now, because we don't know what would be the status of the work
Yves: I think if we need a F2F, better in Europe and earlier
Raphael: Media Fragment WG does NOT plan to meet at TPAC
Precision of #xywh percent
scribe: thread starting at http://lists.w3.org/Archives/Public/public-media-fragment/2011Apr/0022.html
Philip: two issues
<foolip> rounding issue: http://lists.w3.org/Archives/Public/public-media-fragment/2011Apr/0011.html
Philip: first one is
rounding
... second one is the precision
... what is the use case, e.g. cropping a video?
... do we really need the percent syntax?
... the use case seems to be the existence of multiple encoding
in multiple resolutions for the same video
Jack: I think you're right
... the % syntax is for very simple cases, such as take the
half of a video
Philip: but when does it make
sense to do this?
... the change of 4/3 to 16/9 implies percent with
decimal
... so our syntax does not do this
Yves: aspect ratio could be
handled with a new 'aspect' keyword
... but Sylvia was against this, because it is too
complex
... and not enough uses of this
... I'm not for or against the % syntax
... we can let it and see whether there will be
implementations
Jack: I think we should keep it
and see whether there will be implementations
... and take it out if no tools
<davy> http://ninsuna.elis.ugent.be/Media/Showcase/Radiohead
Jack: rather than inventing decimal percentages
Davy: we DO use the percent
syntax !
... in the example above, we need the % to swith resolution
Philip: you have a server and each resolution have different URI
Davy: yes we could do the
computation on the server, but now, the annotations are
independent of the resolution
... annotations are about logical URI
<Yves> conneg on user-agent for different resolution
Jack: the syntax is then more interesting for annotating than cropping
Yves: conneg on UA for different resolution, and cropping are "roughly"
Philip: is this implemented anywhere?
Yves: Opera is adapting content for mobile devices ... they do adapt resolution ?
Philip: yes, but you still have
different URI
... for caching purposes
Yves: not in the case where it is done via proxy
Philip: seems like a corner case
Jack: I think the use case from
Davy, mainly for annotation purpose, is an appealing one
... and not for browsers
Philip: should we write this in the spec?
Raphael: proposal to keep it in
the spec and see the implementations that will do something
with it
... no disagreement
Davy: first some changes, I have
implemented the changes according to last week
... more filters
... more test cases (the ones from Philip)
<davy> http://lists.w3.org/Archives/Public/public-media-fragment/2011Apr/0031.html
Davy: I think we should first
discuss
http://lists.w3.org/Archives/Public/public-media-fragment/2011Apr/0031.html
... Invalid syntax
... #t=3,4,4 is invalid syntax
... what the UA should do
... disagreement: UA only requests setup information (Silvia)
vs whole resource is requested by the UA (Philip)
Jack: I don't really care as soon as it is consistent
Yves: the same
<scribe> ACTION: raphael to ask Silvia if she objects to the decision of requesting the entire resource in case of an invalid syntax [recorded in http://www.w3.org/2011/04/13-mediafrag-minutes.html#action01]
<trackbot> Sorry, couldn't find user - raphael
<scribe> ACTION: troncy to ask Silvia if she objects to the decision of requesting the entire resource in case of an invalid syntax [recorded in http://www.w3.org/2011/04/13-mediafrag-minutes.html#action02]
<trackbot> Created ACTION-216 - Ask Silvia if she objects to the decision of requesting the entire resource in case of an invalid syntax [on Raphaël Troncy - due 2011-04-20].
Davy: Invalid Semantics
... case a): #t=7,3 is invalid semantically ... again same
possibility
<foolip> Range: t:npt=3-7;include-setup
Philip: what does it mean
include-setup? Does it mean to implement the new headers?
... I'm not in favor of implementing this
... in particular when browsers have other means to receive the
setup data
<davy> Range: include-setup
<tomayac> FWIW, in mediafragments.js, all incorrect parameter configurations are silently ignored, a warning is raised if verbose mode is enabled
<tomayac> (following the meeting on IRC)
Jack: for temporal fragment, what
is important is the user experience
... we do not care if he uses byte ranges or our newly
introduced mechanism
Raphael: BIG +1 to Jack
Jack: so if I put #t=7,3, I got
the timeline and no portion selected
... should not be the same with #t=banana?
Philip: there are things that
will be harder to detect during parsing
... e.g. #xywh=150%
<jackjansen> Note that I put up that suggestion (t=7,3 vs t=banana) as a point for discussion, not as my standpoint.
Philip: so #t=7,3 will be ignored, first frame displayed, and NOT the frame at second 7 or 3
<tomayac> in mediafragments.js, most basic things get captured via regexps (like t=2,banana), however, harder ones like start < end are harder (given all the options)
Philip: but #t=15,20 for a video of a duration of 10s will be different
<tomayac> i cant check for end <= video_duration
<tomayac> the default assumption in the lib is to always return the whole resource if anything cant be parsed correctly
Philip: and what about #t=20,80 when the video is of duration 50s ?
Davy: come back to #t=15,20 for a
video of a duration of 10s
... I'm not saying that the UA should issue a range
request
... but if it does, then server should reply with a 416
Jack: what is the user experience?
Davy: I agree with Philip, the
player should seek towards the end (display the last
frame?)
... to be consistent with HTML5
<jackjansen> silvia, the good news is that we've now been able to give you heaps of action points:-)
<silvia> hahaha, sure!
<silvia> I probably just checked my calendar for the usual time, rather than your announcement - sorry :(
<silvia> were you able to agree on things?
<foolip> do we need to support media that doesn't start at 0 ?
<scribe> ACTION: davy to edit the specification for precising what is the user experience when there is an invalid time range [recorded in http://www.w3.org/2011/04/13-mediafrag-minutes.html#action03]
<trackbot> Created ACTION-217 - Edit the specification for precising what is the user experience when there is an invalid time range [on Davy Van Deursen - due 2011-04-20].
<foolip> that comes up in the test case review, let's discuss in due course
<scribe> ACTION: jack to carrefully review the changes made by Davy that will most likely be all over the palce [recorded in http://www.w3.org/2011/04/13-mediafrag-minutes.html#action04]
<trackbot> Created ACTION-218 - Carrefully review the changes made by Davy that will most likely be all over the place [on Jack Jansen - due 2011-04-20].
Raphael: should we postpone the discussion "do we need to support media that doesn't start at 0 ?" to next week ?
Jack: let's do that on the
mailing list
... Dave Singer may have an opinion
<foolip> so, I was muted and afk, so unable to unmute
<foolip> I'm fine with postponing
<foolip> ok
Raphael: summarizing the first issue for Silvia
Silvia: I'm fine with requesting the whole resource
<jackjansen> I have to run: next appointment. See you next week!
Silvia: I'm not able to remember when the include-setup will be used
close ACGTION-217
close ACTION-217
<trackbot> ACTION-217 Edit the specification for precising what is the user experience when there is an invalid time range closed
close ACTION-216
<trackbot> ACTION-216 Ask Silvia if she objects to the decision of requesting the entire resource in case of an invalid syntax closed
Regrets from Davy for next week
<foolip> bye
scribe: we will continue discussing test cases next week