Media Fragments Working Group Teleconference -- 01 Nov 2010

<trackbot> Date: 01 November 2010

Presents: Davy, Jack, Raphael, Silvia (irc), Phillip (irc), Yves

<scribe> Meeting: Media Fragments F2F meeting @TPAC

1. Quick round of introduction

<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

2. Topics to be discussed

http://www.w3.org/2008/WebVideo/Fragments/wiki/SeventhF2FAgenda

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 area
... so we should not have the presentation (browsers) glasses to look at this issue

Raphael: let's summarize the discussion
... 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

ACTION-190?

<trackbot> ACTION-190 -- Raphaël Troncy to update our spec to talk about video intrinsic width -- due 2010-10-27 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/190

http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width

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 fragment
... 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 fragments
... 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?

<silvia> yup

<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 issue
... 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?

<foolip> http://en.wikipedia.org/wiki/Anamorphic_format

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 and height
... 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

<foolip> http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width

<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

Jack: fine

<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."

thanks Silvia

<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." ?

yes Silvia

<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

close ACTION-190

<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> yes

<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 cropping
... 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

<davy> http://ninsuna.elis.ugent.be/MediaFragmentsPlayer

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

[lunch break]

<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?

<foolip> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723

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?

<davy> e.g., http://dev.opera.com/articles/view/custom-html5-video-player-with-css3-and-jquery/

<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

<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> http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid and

<silvia> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video

<silvia> (sorry, but I prefer the whatwg version ;)

fine

<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

3. Track and Name dimensions

<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 byte ranges
... 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 recipes
... 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].

[coffee break]

<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

s/improivement/improvement

Raphael: further, after talking with other browser vendors, I will ask feedback from Chris Double (Mozilla), Eric Carlson (Apple) and Frank Olivier (Microsoft)
... 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.

ISSUE-19?

<trackbot> ISSUE-19 -- Parsing must be defined normatively in the MF spec itself -- open

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19

<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].

4. Summary

Raphael: tomorrow will be about
... 1/ TAG debrief from Yves
... 2/ Extensibility issue with everyone
... 3/ Test Cases presentation from Davy
... 30 min + 2 hours + 1 hour

[meeting adjourned]

- DRAFT -

Media Fragments Working Group Teleconference

01 Nov 2010

Attendees

Contents

1. Quick round of introduction

2. Topics to be discussed

3. Track and Name dimensions

4. Summary

Summary of Action Items

Scribe.perl diagnostic output