See also: IRC log
<trackbot> Date: 01 November 2010
Presents: Davy, Jack, Raphael, Silvia (irc), Phillip (irc), Yves
<scribe> Meeting: Media Fragments F2F meeting @TPAC
<scribe> scribe: raphael
<scribe> scribenick: raphael
Many observers ...
Fran�ois: w3c staff
Ben (Nokia): MAWG member
Hidetaka: developer of Mobile browser, interest in adaptation to small screen
Nobu (NEC ac rep): media analysis (face recognition), interest in standardising results of such analysis
Hiroyuki (Toshiba ac rep): metadata standardisation
Franck (Canon research France): I'm an "old" observer of this group, interest in media fragments standard for streaming media
Pierre Antoine (LIRIS): Uni of Lyon, member of MAWG
Raphael: time dimension
... Philip wonders if the hours should not be optional
... arguing that most video clips are less than an hour duration
... in WebSRT, hours are optional
... should we do the same?
Jack: -0, I'm slightly against
Raphael: the production rules are currently
npt-sec = 1*DIGIT [ "." *DIGIT ] ; definitions taken
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from RFC 2326
npt-hh = 1*DIGIT ; any positive number
npt-mm = 2DIGIT ; 0-59
npt-ss = 2DIGIT ; 0-59
<jackjansen> after some discussion I am now +0, slightly in favor
Raphael: I do remember that
Silvia and Philip was also for making the hours optional
... I suggest to edit the grammar this afternoon with Yves if he does not disagree
<scribe> ACTION: Yves to update the production rules of the time dimension with the npt format for making the hours optional [recorded in http://www.w3.org/2010/11/01-mediafrag-minutes.html#action01]
<trackbot> Created ACTION-191 - Update the production rules of the time dimension with the npt format for making the hours optional [on Yves Lafon - due 2010-11-08].
<silvia> I like the simplicity for the user of the more flexible format
Raphael: smpte format
Davy: the servers is always answering with the same unit than the client
Jack: well, but if the UA sends a
fragment in smpte-30-drop, and the media has another encoding,
then should we do a conversion?
... if the UA sends a npt format, it is clear what the server has to do
<silvia> note that the UA can convert what the user provides to the browser to a common format that can go over the wire
Jack: but if the UA sends one of the smpte definition, and the media happens to use a different format for defining time, then we might have a problem
Davy: the problem is that the UA might not understand the time format in which you are converting to
Raphael: yes Silvia, but then we always convert to npt?
<silvia> hmm.. right - might be better to just hand it through
Jack: we could raise an error, if the UA asks for smpte time codes but that smpte has not been used in the media item
Davy: our current implementation
works with a double conversion
... if the UA sends a smpte-30-drop media fragment and the media item is encoded in smpte-25
... then the servers will convert the smpte-30-drop into npt to get a position and convert it back in smpte-30-drop
Jack: the frame precision will be
most used in the annotation area rather than the presentation
... so we should not have the presentation (browsers) glasses to look at this issue
Raphael: let's summarize the
... smpte time codes are useful for a number of use cases, in particular for annotation use cases
... when generally a UA sends a media fragment request with a time format which is different than the time format used in the media item
... then the server should fallback to answering in npt if it has an understanding of the timeformat requested bu the UA
... if the server does not understand the time format requested by the UA, the default fallback is to ignore the media fragment and send the whole resource
Jack: ok, where this information
should be written ? is this normative ?
... section 5 seems appropriate, I'm tempted to say it should be normative
Raphael: we might have to change the structure of section 5 to make it dimension dependent
<scribe> ACTION: Davy to update the specification to state what the processing should do when media fragments request (time dimension) does not match exactly how the media item has been encoded [recorded in http://www.w3.org/2010/11/01-mediafrag-minutes.html#action02]
<trackbot> Created ACTION-192 - Update the specification to state what the processing should do when media fragments request (time dimension) does not match exactly how the media item has been encoded [on Davy Van Deursen - due 2010-11-08].
Raphael: let's discuss the space dimension
<trackbot> ACTION-190 -- Raphaël Troncy to update our spec to talk about video intrinsic width -- due 2010-10-27 -- OPEN
Room trying to understand the issue
Room having a laugh reading http://www.emdpi.com/csspixel.html
Jack: in section 7, we could put a note for phrasing this issue. Philip is our HTML5 expert to do this phrasing
Davy: we should have another
section 7.x for browsers, how they should render media
... different than 7.1 which is for general clients
Jack: 7.1 should be browsers, 7.2
general clients, 7.3 servers
... + a note for stating that all sub-sections are not mutually exclusive
Raphael: actually, 7.1 = browsers, 7.2 general display clients, 7.3 all clients, 7.4 servers
Jack: then in 7.1, we could have
the result of the action 190, the mapping to css pixels
... I would be happy that Philip + Silvia draws a list of all things that matter to a HTML5 browser rendering client for media fragments
... perhaps put a warning that the content of this new section is based on the current state of HTML5 discussion as per ... <date>
<silvia> so, do you want a description that spatial fragments should be spliced in html5 elements?
<foolip> anyone know when we're going to have the TPAC calls? I can't find anything definitive in my mail
[back from coffee break]
Silvia, I'm not sure I understand your question
Philip, we have started the Media Fragments WG f2f meeting at TPAC
scribe: agenda is at http://www.w3.org/2008/WebVideo/Fragments/wiki/SeventhF2FAgenda (add your topics that you would like to be discussed)
<jackjansen> foolip, currently not
<silvia> raphael: my question was about what should be added to a browser section (html section?) in 7.1
<silvia> I wondered if it was ok to add spatial fragments as splicing the image
Philip, we can setup the call now if you're ready
<foolip> ok, where are you in the agenda/
Silvia, we are exactly dicussing what should we add to this new section 7.1
scribe: so far, the pixels discussion
Raphael: Philip, we wonder
whether you and Silvia could write down a list of items that
(HTML5) browsers need to consider when implementing media
... but notes that are not applicable to general rendering clients and already written
... for example, the pixels discussion
... could you phrase the issue of what mapping to CSS pixels should be done for example?
Silvia, by splicing, you mean cropping?
<foolip> the issue of aspect ratio isn't browser-specific, all UAs would have to deal with the issue. "CSS-pixels" is actually just the size after applying aspect ratio scaling in one dimension
Sylvia, we have a paragraph so far that talk about either highlighting or cropping
scribe: which one makes more sense ?
<jackjansen> invite zakim
join zakim #mediafrag
Silvia, Philip, you can now dial in and we will see if it works
Philip: this is not a CSS
... the question is when do we have a xywh dimension, does it apply before of after that there was a aspect ratio transform
Jack: the original media item is 1080, but the device is 720 width, so which pixels should be considered when applying a media fragment xywh?
Jack: I think we have trouble to understand what exactly is the CSS pixel concept and therefore the issue
Philip: the container format has tow information, the preferred display size and the real size
<foolip> For example, WebM has Pixel width/height and Display width/height. This is the same as Matroska: http://www.matroska.org/technical/specs/index.html
<foolip> Actually, Matroska also has PixelCropBottom, etc
Jack: in QuickTime 7, open a movie you can choose between normal size and display size
<foolip> The point is that the physical pixels aren't always the same as the display size
ok Philip, we understand now the issue
Philip: CSS pixels are display pixels
<foolip> "information rich"?
<silvia> I would suggest that there are three levels: 1. what is encoded in the stream, 2. what the browser receives after decoding, 3. what the browser displays after scaling etc
<foolip> silvia, isn't 1 and 2 the same?
<silvia> I think we should attach the pixel count to 2.
<silvia> not really - there is pixel crop in several formats - ogg does it, too
<silvia> I would suggest not to count those pixels that are cropped in the format
<foolip> silvia, I would consider the effect of crop+scaling as one step, but anyway...
<silvia> a media fragment URI that is used by itself in the browser address bar has no scaling applied to the video - it's that display to which I would attach the cropping
<silvia> (when I said "cropped in the format", I meant PixelCropBottom and stuff like that)
<foolip> the scaling I'm talking about is horizontal OR vertical scaling to get the correct aspect ratio, not scaling to fit the video in a webpage
<foolip> so, the dimension I suggest we use are the same as we see in HTMLVideoElement.videoWidth and .videoHeight
<foolip> I assume we agree but don't understand each other :)
<silvia> except that HTMLVideoElement.videoWidth and .videoHeight have the @height and @width scaling of the <video> element executed on it
<foolip> silvia, no, it doesn't
<foolip> at least not in Opera or according to the spec
<silvia> ah, ok, then it is those width and height indeed
<foolip> right :)
<silvia> that's indeed what I meant with option 2
Jack: my proposal is that when
the container format has multiple interpretations of the width
... then we should fall back to the display width and height (aka CSS pixels)
... and we could give the example of the Anamorphic format versus the example of vector graphics
<silvia> we could just simply refer to the HTMLVideoElement.videoWidth and .videoHeight description
<foolip> I disagree, this is not a implementor note, we need to say precisely what to do, as with everything else.
<foolip> No need for new sections, just say it where we define xywh
<silvia> no, it's bad to leave such things open for interpretation
<silvia> I cannot think of a situation where it would be desirable to use a different meaning
<foolip> sorry, call dropped
<silvia> at least write it into the HTML / browser section in this way as a requirement
People in the room tends also to think that it should be specified when we talk about xywh
<foolip> I think that in general we should have as few "implementor notes" as possible, if we're not sure about how to implement something then that's a very dangerous thing, IMO
<silvia> I agree
Jack: and if someone in the future is interested in physical pixels, then they should invent "xywh-physical" for addressing them
<jackjansen> I agree too.
ok, great consensus
<jackjansen> Section 7 is for "practicality beats purity"
<silvia> why not re-use the text from the HTML5 spec - or at least link to it?
Raphael: I need someone to edit
the section 4.3.2 to state about which pixels we are talking
about (actually CSS pixels) and refer to HTML5 spec
... no reference to HTML5 spec, sorry
... we cannot because we will be REC before them
<silvia> but we can copy the text
Silvia, or Philip, could you add this sentence now?
<silvia> sure… give me a sec
<jackjansen> I don't think we want that exact text: it had us baffled this morngin
phrase it differently, BECAUSE we haven't udnerstand the HTML5 text in a first place
scribe: so the phrasing was not good enough
<silvia> oh - what text do you want then?
<silvia> why don't you add it then?
<foolip> If there's something wrong with the phrasing, have it changed in HTML5 first, please :)
<foolip> just file a bug and it will happen
Philip, you're the one to make changes in the HTML5 spec :-)
<foolip> or, tell me what's difficult to understand and I'll make it happen
let's edit this sentence in our spec on irc
<silvia> I really don't see how it can be formulated better
First sentence reads:
Spatial clipping selects an area of pixels from visual media streams. For this release of the media fragment specification, only rectangular selections are supported. The rectangle can be specified as pixel coordinates or percentages.
<silvia> it refers to CSS pixels and explains what needs to be taken care of
I suggest we add afterwards a sentence talking about CSS pixels
Which sentence do you want to re-use exactly?
<silvia> s/specified as pixel coordinates or pecentages/specified as CSS pixel coordinates or percentages/
<silvia> then explain CSS pixels for video the way that HTML5 does
OK silvia, so you want to add this sentence afterwards?
<foolip> It seems to me things would be less confusing if we actually used CSS syntax here, i.e. 10px or 10%. Then it's more obvious that px refers to the same thing that it would in CSS.
"The intrinsic width and intrinsic height of the media resource are the dimensions of the resource in CSS pixels after taking into account the resource's dimensions, aspect ratio, clean aperture, resolution, and so forth, as defined for the format used by the resource. If an anamorphic format does not define how to apply the aspect ratio to the video data's dimensions to obtain the "correct" dimensions, then the user agent must apply the ratio by increas
Philip, currently, our syntax is: #xywh=160,120,320,240 or #xywh=pixel:160,120,320,240
<silvia> We could write:
<foolip> Yep. Never mind the syntax for now, that's easy to change later.
<silvia> "CSS pixels are pixels as calculated after taking into account the resource's dimensions, aspect ratio, clean aperture, resolution, and so forth, as defined for the format used by the resource. If an anamorphic format does not define how to apply the aspect ratio to the video data's dimensions to obtain the "correct" dimensions, then the user agent must apply the ratio by increasing one dimension and leaving the other unchanged."
<foolip> I'm not joking at all, but let's focus on the issue at hand.
The only issue for Jack is that we should perhaps not name them "CSS pixels", they have nothing to do with CSS
<silvia> foolip: does that sentence sound correct still? it's not quite what html5 says, but CSS pixels aren't defined there...
<silvia> Jack: in html5 they are relevant as CSS pixels, because CSS scaling and stuff is applied to them
<silvia> and we might as well make that link here
<foolip> Uh, I think copying the text at all is a pretty bad idea, especially if we don't link to where it was copied from.
Philip, in a recommendation, you should avoid linking to a WD or any other document which is not a REC
<silvia> we should of course link to it to also say that we mean the same thing as HTML5
scribe: because of dependency issue
<silvia> I would make an exception here
<foolip> I can see why that general policy exists, but clearly it's harmful in this instance.
scribe: what's happened if the
HTML5 spec removes this paragraph at REC stage after you have
been rec? You need to publish an erratum
... too dangerous
<silvia> no, there's no chance that section will be removed
Silvia, we can make exceptions for many things then, and this is simply not acceptable
scribe: you know St Thomas
<silvia> no, I wouldn't make exceptions for many things - but in this instance I woudl
Silvia, perhaps you want to make an exception, but the director will NOT
scribe: this is the shortcut to get a veto from the W3C director (and many members by the way)
<silvia> maybe he would - it would be harmful not to make an exception here, because we want to mean the same thing as HTML5
<foolip> So there can't be any links to documents that aren't in REC?
great, we make our own sentence, and that's fine
not in normative part Philip
and this is a 20 years old practice
<foolip> OK, so put it in a note then.
<jackjansen> "If the underlying media format has multiple interpretations of pixel dimensions, then MF pixels MUST be interpreted in the display coordinates"
Jack: "Pixels coordinates are interpreted after taking into account the resource's dimensions, aspect ratio, clean aperture, resolution, and so forth, as defined for the format used by the resource."
<silvia> maybe the note can say that it means the same as what is defined as intrinsic width/height on the video in the draft HTML5 spec
Philip: could we add as well " If an anamorphic format does not define how to apply the aspect ratio to the video data's dimensions to obtain the "correct" dimensions, then the user agent must apply the ratio by increasing one dimension and leaving the other unchanged." ?
<foolip> Note: this is equivalent to intrinsic width and height in HTML5 <http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width>
<jackjansen> "The pixel coordinates defined in 4.3.2 are intended to be identical to the "CSS pixels" defined by HTML5"
<foolip> different section?
<foolip> not "CSS pixels", intrinsic width and height
<jackjansen> filip, right
<trackbot> ACTION-190 Update our spec to talk about video intrinsic width closed
Changes have been made in section 4.3.2: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space
scribe: and in section 7.1: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#media-fragment-browser
anyone UN-happy, please, speak
<foolip> I'd rather section 7.1 didn't exist, and the note being put directly after the copied text in http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space
<silvia> ah, yes, I agree with Philip actually - seeing as it should be used everywhere to mean the same thing
Raphael: highlight vs
... should we say more than the current pararaph ?
"For a spatial URI fragment, we foresee two distinct use cases: highlighting the spatial region in-context and cropping to the region. In the first case, the spatial region could be indicated by means of a bounding box or the background (i.e., all the pixels that are not contained within the region) could be blurred or darkened. In the second case, the region alone would be presented as a cropped area. How a document author specifies which use case is in
in particular, should we talk now with CSS?
<foolip> I think we should just rename xywh to crop.
<foolip> Annotations don't care about display anyway.
Jack: for time, we have both, cropping (query) and highlihting (in context view), why you would like to make it different for space?
Philip: because there is a good reason for time, I don't see it for space
Jack: but annotation use case is about addressing pixels, not cropping or highlighting
<silvia> maybe for the visual domain it might make sense to have them explicitly different - then annotation ppl can use xywh and browsers can use crop? (not sure...)
<silvia> ninsuna does nothing on the server for regions
<silvia> I haven't seen the ninsuna client yet, I think...
it is on the web silvia
we have demoed it everywhere
<silvia> I had only seen the plugin
Silvia, 2 F2F ago, we already showed the Flash client from Davy, I'm sure you have commented on it, so you must have seen it :-)
<silvia> so, xywh=247,156,129,206 already means highlighting to everyone?
<silvia> so, crop=247,156,129,206 could mean cropping - would be the easy way out actually...
scribe: there are slides about it at the Barcelona F2F meeting, look at our meetings dir in our web space
<jackjansen> silvia, xywh doesn't mean highlighting nor cropping. It means addressing, nothing more.
<silvia> because it ends up in in-compatible interpretations of the URI
<silvia> when a Web developer cannot rely on what will be presented in all browsers the same way, it's in-compatible and under-specified
Yes Silvia, but this is not our fault but the fault of HTML5
scribe: what Jack is saying is
that for us, it should be an implementation note, but for
HTML5, the behavior should be normative
... I guess the issue is that rendering in browsers should be specified in HTML5 and not in Media Fragments
... media fragments is just about "addressing"
<silvia> we should put it into the browser section at minimum
Philip: then, if it is the case, we should remove all the section 7 implementers note, rather than having half in our spec and half in other documents
Yes silvia, this is what Jack proposes
<silvia> and if we want browsers to support both display mechanisms, we need two different means of addressing
<silvia> I'm warming to the thought of "crop"
Slvia, you are adapting the display mechanism to the address while it should be the contrary
<silvia> no, I am saying that we are under-specifying the mechanism
<foolip> Anyway, can we take a step back and see what we're actually discussing?
<silvia> html fragments also always mean the same in all applications
if you can "style" what you address, then you don't need to invent 10 terms for 10 different displays of the same region addressed, right ?
<davy> CSS descriptors could be used for displaying media fragments
<foolip> I really doubt we'll see CSS extensions specifically for xywh, because it'd have to be very complicated to do things that are simple to do without it.
<silvia> I'm playing with the thought and I can only see advantages this far
<foolip> are we starting again soon?
Philip: there will be no other
people that will specify this except us
... so either we make it in our spec or we make it in the HTML5 spec, but it will be us
Raphael: where the rendering of a media fragment according to the space dimension should be specified?
Philip: I don't care what should happen and where, I care about having this specified somewhere so that there is no interoperability or different behaviors in various browsers
Jack: I think we should just have
a non normative text in the Media Fragment spec. We should
rather propose a text to HTML5, and they vote if they want to
include it or not
... yes, cropping seems to be the best default solution for html browsers
... let's propose a crop only text to HTML5 and see WebApps or CSS complaint about
Philip: this should not be
something that goes towards mime type registration?
... So shouldn't we write something, a hook, for enabling such a mime type registration
<foolip> I said that I think I agree with Ian that this *should* go into MIME type registrations
thanks for the reformulation
<foolip> but, I'm not sure
<foolip> it would be terrible if two different MIME types defined things differently
<foolip> In reality, browsers will just do the same thing for all types...
<silvia> we never really finished the discussion about how to get uptake by the media formats on this - IIRC Raphael or Yves had a discussion with TBL about how that could be done without having to update every single mime type registration - can somebody clarify where we're at with that?
Yves has further discussed this with TAG and TimBL last weeks and this morning
scribe: he will update us later today or tomorrow morning
Jack is editing section 7 now, to clarify that browsers should crop spatial fragments
<foolip> Adding non-normative text doesn't change anything.
<foolip> There should be normative text *somewhere*.
scribe: and that other clients can crop or highlight regions
YES, Philip, this is the first part
<foolip> Also, special-casing browsers is very atypical.
the second is to send this text being edited to HTML5 and see if they want it *normatively*
if we do: s / browsers / HTML5 renderers,do you prefer ?
<silvia> if we are making a browser section, we might as well make our section normative
why silvia ?
this is implementation specific
<silvia> no, every HTML rendering UA must do the same thing - otherwise it's not much of a standard, right?
<jackjansen> please read and review: I tend to be somewhat terse in my prose...
Jack: if we like this, how do we push this to HTML5 WG?
<silvia> it's not prescriptive enough for HTML5
<foolip> I don't think it's fruitful to try to work this out in real time, right now.
<silvia> but I'd be happy to make a proposal through that bug - it's as simple as adding the spec text to the bug to start a discussion and get a change
<davy> Is the rendering of the video timeline a similar issue?
<foolip> It's similar, people won't use browser-native highlighting for the same reason they won't use native controls, because you can't customize how it looks, and no one is working on any CSS extensions to fix it.
Raphael: Silvia, I'm proposing to
edit the bug, but feel free to do it
... my plan was to add the paragraph in 7.2 in the bug entry
... and let HTML5 decides what to put in their spec
<silvia> no, not that way - it's got to be terse and it has to be addressed at a specific section in the spec where it should go
<silvia> think about as though you are the editor of the spec and you are proposing what text has to go in
<silvia> more like a patch
<foolip> We shouldn't suggest any specific text, let's just say what we want and let Ian figure out the details.
What about saying Ian to make the text he wants from
"For a spatial URI fragment, we foresee two distinct use cases: highlighting the spatial region in-context and cropping to the region. In the first case, the spatial region could be indicated by means of a bounding box or the background (i.e., all the pixels that are not contained within the region) could be blurred or darkened. In the second case, the region alone would be presented as a cropped area."
<silvia> really? he'll just say it doesn't belong there..
<foolip> If he's wrong, then we should tell him why :)
<foolip> I'm not sure myself, at this point.
Silvia, Ian said it should belong to the mime type registration (not in HTML5, not in Media Fragment), but it will NOT appear there
<silvia> that's a second thing: we need a good answer for why it's not going into mime type registrations
scribe: and he made it appear in the HTML5 spec for the HTML fragment spec ... not in a separate mime type registration document
Silvia, do you want to edit the bug?
scribe: so we can move on?
<silvia> at minimum there are these sections affected:
<silvia> (sorry, but I prefer the whatwg version ;)
<silvia> (it's more up-to-date)
<foolip> and it's green :)
<silvia> I'll update the bug after we have an answer to the question about mime type registrations
Raphael: we wait for the debrief of Yves regarding the discussion in TAG
<silvia> I also added a topic to our discussion list about what to do for video fragment addressing when it's about videos on a web page
Silvia, I put it in the agenda too
<silvia> I think that may also be relevant
scribe: and I observe we have
already discussed this several times
... and already come to a conclusion
... but you want to re-open the can of worms :-)
<silvia> for now we can collect all these things in the "browser" section of "our" spec
<silvia> I do because we are moving closer to real-world use and we have to do more than initially intended
Davy: Regarding the track
dimensions, it is almost always impossible to write all the
... so we will _always_ perform a redirect
... hence, if a media fragment URI uses a # with the track dimension
... we redirect to the '?' parameter
... see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-UA-mapped-changed
<scribe> ACTION: Erik to make a schema for this recipe [recorded in http://www.w3.org/2010/11/01-mediafrag-minutes.html#action03]
<trackbot> Created ACTION-193 - Make a schema for this recipe [on Erik Mannens - due 2010-11-08].
Raphael: the section 5 is
organized per recipes
... but it is confusing when one looks at the dimension
... hence, spatial dimension has no dimension (no request is sent to the server)
... the track dimension is always in the case of server-redirect recipe
... most likely, the same for name dimension
... therefore, only the time dimension can use all these recipes
... should we not write this down up in the section 5?
s/has no dimension/has no recipe
Raphael: we have 3 types or
... UA mapped byte ranges ... for the temporal dimension
... Server mapped byte ranges ... mainly for legacy formats
... Server triggered redirect ... for the track and name dimensions
... further, for the space dimension, no range request is issued
... I suggest to add this in the intro of Section 5
<scribe> ACTION: raphael to add an intro paragraph in the section 5 to explain which recipes is useful for which dimension [recorded in http://www.w3.org/2010/11/01-mediafrag-minutes.html#action04]
<trackbot> Sorry, couldn't find user - raphael
<scribe> ACTION: troncy to add an intro paragraph in the section 5 to explain which recipes is useful for which dimension [recorded in http://www.w3.org/2010/11/01-mediafrag-minutes.html#action05]
<trackbot> Created ACTION-194 - Add an intro paragraph in the section 5 to explain which recipes is useful for which dimension [on Raphaël Troncy - due 2010-11-08].
<foolip> let me know when you start again
[back from Coffee break]
Raphael: useful coffee break
<foolip> Should I call in?
<foolip> What's next?
Raphael: Regarding CSS styling of media fragment in the spatial dimension for rendering, CSS co-chair Daniel Glazman suggested me to write our text to their mailing list for improivement
Raphael: further, after talking
with other browser vendors, I will ask feedback from Chris
Double (Mozilla), Eric Carlson (Apple) and Frank Olivier
... that all deal with the video elements in their browsers
<foolip> And what about Chrome developers?
<foolip> will search mail
Raphael: I would like we discuss about the name dimension
Davy: we see the name dimension
as more general that what media containers could do
... but we have no implementation yet
Philip: name dimension is really
dependent on container formats
... we have chapter names in WebM (mkv)
... we have cue points in MP4
<foolip> Sorry, I can't find the Chrome developer's name...
I will try to find out with corridor discussion this week
Jack: perhaps this is tightly correlated to the extensibility discussion we have to do
Jack asked frankly, if anyone feels bad in removing "id" dimension from the spec?
Philip: no strong opinion about it, if not implemented, it should be out of the spec as a general principle
Raphael: I like to have this feature in, but I'm aware we need implementation for this
Davy: our plan is to not rely on the container format but on media annotations
<foolip> Will we have time to discuss ISSUE-19 today? If not, I'll be heading home.
<trackbot> ISSUE-19 -- Parsing must be defined normatively in the MF spec itself -- open
<foolip> <video src="video.webm#t=10">
<davy> media fragment identifiers are only meaningful for media resources, not for HTML documents
<davy> if sites like YouTube want to give a meaning to #t=10 applied to an HTML document containing a video, then it is the responsibility of these sites to make sure that the media fragment identifier applied to the HTML document is appended to the media resource URI
<davy> The media fragments spec will say nothing about the meaning of ....html#t=10,20
Raphael: but a range request will
still be issued from the browser
... if the hash is used on the address bar of the browser
... in all cases
<scribe> ACTION: davy to add a paragraph in the section 7.1 to specify that video, audio, img or any href is all treated similarly (range request issued when facing a media fragment) [recorded in http://www.w3.org/2010/11/01-mediafrag-minutes.html#action06]
<trackbot> Created ACTION-195 - Add a paragraph in the section 7.1 to specify that video, audio, img or any href is all treated similarly (range request issued when facing a media fragment) [on Davy Van Deursen - due 2010-11-08].
Raphael: tomorrow will be
... 1/ TAG debrief from Yves
... 2/ Extensibility issue with everyone
... 3/ Test Cases presentation from Davy
... 30 min + 2 hours + 1 hour
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Idetaca/Idetaka/ Succeeded: s/Idetaka/Hidetaka/ Succeeded: s/Frank/Franck/ Succeeded: s/Nob (NRC ac rep)/Nobu (NEC ac rep)/ Succeeded: s/Toshipa/Toshiba/ Succeeded: s/back in smpte-25/back in smpte-30-drop/ Succeeded: s/if should be normative/it should be normative/ Succeeded: s/other/all/ Succeeded: s/udnerstand/understand/ FAILED: s/specified as pixel coordinates or pecentages/specified as CSS pixel coordinates or percentages/ Succeeded: s/dimension/coordinates/ Succeeded: s/normative/non normative/ Succeeded: s/HTML media fragment/HTML fragment/ FAILED: s/has no dimension/has no recipe/ FAILED: s/improivement/improvement/ Found Scribe: raphael Inferring ScribeNick: raphael Found ScribeNick: raphael WARNING: Replacing list of attendees. Old list: Roseraie_1 foolip silvia New list: Roseraie_1 Philip WARNING: Replacing list of attendees. Old list: Roseraie_1 Philip New list: Roseraie_1 Default Present: Roseraie_1 Present: Roseraie_1 WARNING: Fewer than 3 people found for Present list! Regrets: Erik Found Date: 01 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/01-mediafrag-minutes.html People with action items: davy erik raphael troncy yves[End of scribe.perl diagnostic output]