Media Fragments Working Group Teleconference

<trackbot> Date: 09 March 2010

<scribe> scribenick: raphael

<scribe> Scribe: Raphael

1. First day summary

Raphael: I would suggest to start today's agenda with 2 short discussion:
... a) What should be the delimiter in the URI for specifying multiple tracks: comma or semi-colon

<foolip> was it understood and found acceptable that whatever separator we use can then not be part of the track name, even if it's percent-encoded?

Raphael: b) Whether we should revisit the delimiter in the URI for specifying the time dimension and use the dash instead of the comma

Philip, no, the separator could be used in a track (or id) name if it is percent-encoded

Why would you you prevent to use it?

<foolip> Because percent-decoding happens before matching against each syntax

<foolip> I sent a rather long mail about layering just now, somewhat related.

Philip, the room agrees with what you just said ... there are 2 solutions

a) We quote :-)

b) We forbid multiple tracks selection for the 1.0 version, so there is no delim and no problem

<Yves> basically, the only bulletproof solution is: don't use names :)

<jackjansen> trackbot, minutes?

<trackbot> Sorry, jackjansen, I don't understand 'trackbot, minutes?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<foolip> why was track=a&track=b not ok?

<jackjansen> pointer

Philip, we will discuss this on the phone in 5 minutes, could you join?

<foolip> wait a sec

Philip, track=a&track=b is not valid since any fragment with multiple occurrence of 't' or 'xywh' or 'track' or 'id' will be invalid

<foolip> phone number?

Philip, hold on, phone in 5 minutes

<foolip> ok

<foolip> raphael: we can just make multiple occurences of track valid, can't we?

<jackjansen> Philip, that would break for libraries that decode only the first of each name=value pairs

<foolip> jackjansen: yes, but so would t=1&t=2, which processing needs to handle (but it shouldn't be valid)

Philip, t=1&t=2 is indeed invalid per our syntax

<foolip> raphael: invalid, but the result of processing it the same as if t=2 was used

the problem is that if you have multiple occurences of key=value with the same key, is that some libraries just take the last one

<foolip> yes, which is why there is a note in the spec warning about the issue

<foolip> should I call in now?

<Yves> what if somebody else decide that t=1&t=2 means something else? Like generate two streams, starting at different times?

<Yves> somebody else, meaning out of our spec

<Yves> we shouldn't define an uber-error-recovery mechanism that forbid all reuse and enhancements

<foolip> Yves: they would simply be violating our spec

so this is not the same: in case of #t=10&t=20 ... invalid fragment, the complete resource is sent back

<Yves> foolip, yes, so if you implement only mediafrag, you'll get all the data, if you implement their spec, you'll do the "right thing"

<foolip> having country code troubles

<foolip> I thought we had already discussed this enough times

Philip, what did we already discuss enough?

<foolip> nope, dialing in gets me a busy tone or nothing at all

Philip, on the phone Silvia argues, based on section 2.2 of the URI draft, that all reserved characters are treated equally

<silvia> what jack just explained was how I understood it

scribe: so #track=audio,video will work

<silvia> we have the reserved characters exactly for the purpose of making sub-delimiters

<foolip> raphael: tried +1 and +44

<silvia> the percent-encoding should not happen on the complete content value, but only on the segmented values (after separating on sub-delimiters)

<foolip> raphael: just tried it, no luck

Philip, Silvia just contradicts your previous statement, re: we will not be able to have a comma in a track name

<silvia> we just need to make the parsing & %encoding different

<foolip> we can make it work, but then we will also have to change how name-value processing works and make percent decoding happen later

Yes Philip

<foolip> another incompatability with existing languages, just to be clear

<foolip> if the argument against track=a&track=b is that it breaks existing tools, using a new separator does the same

<foolip> are there other problems with track=a&track=b?

Philip, the WG_Room + Silvia thinks that using one of the subdelim as defined in URI spec is the right thing to do ... subdelim are made for that

scribe: so not breaking existing tools

<foolip> raphael: sure, but is it worth introducing more incompatibilities?

<foolip> name-value lists already provides a way to repeat the same name

Jack: as soon as there is a UTF-8 character, you will need to decode the string and re-encode the string according to RFC2047
... so we don't need to have a correlation between what is in the URI and what ends-up in the HTPP headers

Silvia: yes, but in most of the case, there will be ASCII characters so we could ease implementers work

Jack: this is an invit for lazing coding
... I agree with you with the practical case, but we are editing a spec
... we should try to follow patterns set by other RFC spec

<mhausenblas> hu?

<mhausenblas> I dropped ...

Silvia: i would not object on that ... you have a point

Raphael: should we stand with yesterday's resolution, i.e. keep the semi-colon as separator?

Jack: I have checked 2 cgi libraries and indeed, Philip is right, that makes in practice the use of ';' forbidden in track names

<foolip> I disagree with using a separator

<Yves> Yves is ok with multiple &track=

<foolip> let's continue, enough time wasted on phones today :)

Proposal: a new resolution that contradicts yesterday's resolution. Multiple tracks selection will be possible using multiple occurrence of the keyword 'track' (e.g.: #track=audio&track=video)

<jackjansen> +1

+1

<Yves> +1

<foolip> +1

<mhausenblas> +1

<davy> +1

<jackjansen> :-)

<erik> +1

<silvia> +1

RESOLUTION: a new resolution that contradicts yesterday's resolution. Multiple tracks selection will be possible using multiple occurrence of the keyword 'track' (e.g.: #track=audio&track=video)

<jackjansen> perl..... brrr......

<foolip> is the delimiter controversial?

<jackjansen> hihi

Raphael: we need to apply many changes in the whole document

Philip: I have also edited the spec

Raphael: please check in

<foolip> breaking up too much right now

<foolip> silvia: which bridge did you use?

<foolip> no, there's no CVS web interface that I know of

<scribe> ACTION: Yves to change the formal syntax to reflect that we don't need a subdelim for selecting multiple tracks but we allow multiple track= in the URI [recorded in http://www.w3.org/2010/03/09-mediafrag-minutes.html#action01]

<trackbot> Created ACTION-152 - Change the formal syntax to reflect that we don't need a subdelim for selecting multiple tracks but we allow multiple track= in the URI [on Yves Lafon - due 2010-03-16].

<scribe> ACTION: Raphael to review the complete document and check whether there are mroe references to uniqueness [recorded in http://www.w3.org/2010/03/09-mediafrag-minutes.html#action02]

<trackbot> Sorry, couldn't find user - Raphael

<scribe> ACTION: troncy to review the complete document and check whether there are mroe references to uniqueness [recorded in http://www.w3.org/2010/03/09-mediafrag-minutes.html#action03]

<trackbot> Created ACTION-153 - Review the complete document and check whether there are more references to uniqueness [on Raphaël Troncy - due 2010-03-16].

<foolip> Yves: I will commit now, as it conflicts with the action you just got

Short dicussion: re-visiting the use of comma in definition of temporal definition in URI

scribe: Conrad proposed to use a dash
... Rejected by all the group
... it just introduces more problem, uri syntax is not correlated to header syntax anyway

<foolip> why is the delimiter important?

Conrad, object formally if you're not satisfied with this answer

2. HTTP headers discussion

Back to the other objection from Conrad, sent yesterday

scribe: the use of the Range headers when there is another unit than bytes
... we miss so far in our discussion the fact that there is synthetic headers
... see also: http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html

Silvia, Philip: look at http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaFragmentHeaders

<conrad> raphael, I'm ok with not using a dash for start-end specification

Conrad, in the URL?

Conrad, are you ok with using a comma in the URL?, i.e. #t=10,20

<foolip> committed some stuff, should make some of you cringe in pain ;)

<foolip> raphael: except CVS is so terrible, when will we switch to git?

Silvia: is the Content-Range in other units purely descriptive? ... I would think so

<Yves> http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html

<silvia> HTTP/1.1 206 blah

<silvia> Content-Range: t:npt=10-20/60

<silvia> Content-Range-Equivalent: bytes=16384-32768/65536

<silvia> instead return:

<silvia> HTTP/1.1 206 blah

<silvia> Content-Range-Equivalent: t:npt=10-20/60

<silvia> Content-Range: bytes=16384-32768/65536

Silvia: we are not sending 16 kB but 20 kB since they are also the synthetic headers
... so your change is just wrong

<conrad> raphael, yes i am ok with using a comma in the url

Jack: we want to stop old-fashioned try to cache fragments

Silvia: NO NO NO, we don't send synthetic headers
... this is what we have discussed the last 1/2 year
... we return in the fragment only the bytes of the original resources

<conrad> i don't recall that we agreed not to send synthetic headers, obviously we need to supply both the headers required for decode ("synthetic") and the media data

Jack: for queries, we must have synthetic headers, it is OK, this is a new resource

<conrad> if we use some form of referral to byte ranges for the media data, fine, but that is optional

<conrad> that is a different issue to the overloading of Range though

Silvia: indeed, we haven't taken yet a formal resolution

Raphael: perhaps it is now time for :-)
... so let's discuss whether there will be synthetic headers exchange in the case of fragments

<conrad> i suggest that the response to a fragment url is a valid media stream

<conrad> whether that does or doesn't require generating new headers, tailer data, intermediate data, referral files (.m3u, adaptive streaming etc.) or whatever is media-dependent

Conrad, does it mean to send synthetic headers?

<conrad> raphael, for some media types like a raw ogg stream, sure; but that is not something to be specified by mfwg

<conrad> here we can propose a mechanism for optimising that transfer, like an optional way of saying that some part of the representation can equivalently be gotten by a byte range retrieval

<jackjansen> silvia, you become unintelligeble

<foolip> breaking up...

<Yves> jack was talking about phone quality ;)

<foolip> in short, Silvia is 100% right

<silvia> conrad: no, the response to a fragment is a byte range - no media file headers

<mhausenblas> Michael: I can't hear you guys anymore

<silvia> only the response to a query needs to headers

Raphael: indeed, there is a contradiction between Silvia and Conrad's view

<conrad> so where do you get the headers (required for decode) from?

Conrad, with another request

<silvia> e.g. a Web browser has already set itself up for decoding a media file when it is asking for a later byte range

<mhausenblas> hm ... I can't get in. damn ... trying other line

<conrad> in that case there is no new http header transaction to be specified anyway

<conrad> it is just a client-side seek

<mhausenblas> oh - just got a mail from admins. seems like they have to reboot out (VoIP-based) phone system ... will try again as soon as the system is up again

<foolip> will try calling into another bridge when summoned the next time

<mhausenblas> thanks raphael but I really really want to dail back in ASAP

<silvia> conrad: no, the idea of 5.2.2 is to make an improvement over 5.2.1: e.g. instead of having to do bisection search with Ogg over network, you get to simply ask the server for the right byte ranges by asking for the time range or track ..

<silvia> all URI fragment requests have to be handled the same way - none will require re-retrieving artificial file headers

<foolip> I agree with Silvia that it's unlikely any browser will implement these headers

<foolip> if you have an index, there's just no need.

<silvia> for old Ogg files without an index, it still makes sense

<silvia> we will not ever have all Ogg files with index and thus this is a way to improve on the bisection search problem

<foolip> yes, but that's probably not reason enough to spend resources on it, we'd just tell people to use footool to add an index

<foolip> I of course only make guesses on behalf of Opera

<conrad> silvia, sure, in the case of no server interaction that makes perfect sense

<silvia> well, it was the original motiviation for section 5.2.2 - but it may not be relevant much longer (unless the video element starts supporting other such file formats)

<silvia> bah! but there *is* server interaction!

Raphael: Silvia, Conrad and Philip, we are discussing in the room whether a fragment request should retrieve a playable resource (with synthetic headers) or just bytes from the original resource, or a multi-part reply

<silvia> anyway - the situation for query is a different one and we can still use all of the above arguments to sort out the query case, which will indeed need to return a full media resource

<foolip> raphael: the original resource, without a shadow of a doubt.

Yes, Silvia, we don't talk about query, since it is easy and we don't need to specify headers anyway ... it already works

Jack: synthetic headers gives us problem

<silvia> if we introduce header retrieval into media fragments now, we have to also change the way in which 5.2.1 works - and that doesn't make sense, because that's how browser vendors right now work

Jack: I'm also more and more convinced that we should not sent them on the wire in the fragment case

<silvia> not dealing with synthetic headers solves sooo many problems

<silvia> if we introduce synthetic headers, we get a new media resource with a different start and end time - which will result in a different presentation

<silvia> that should really be reserved for query only

<foolip> indeed

<silvia> it's the fundamental difference between fragments and queries: fragments === byte range requests, query === new resource

<Yves> in that case we _never_ need anything else than byte ranges

<jackjansen> silvia, the 5.2.1 case is different, it uses byte-ranges

<Yves> and we always need 2 requests at minimum

<silvia> other than in the case where the UA cannot resolve a time range to a byte range

<jackjansen> but that doesn't invalidate the other points

<silvia> no, Yves, the UA can send a request to the server for a time range and the server can reply with the appropriate byte range

<silvia> that is what 5.2.2 expresses

<Yves> no because it's not playable, so you need extra information beforehand

<Yves> (or after)

<silvia> 5.2.2 and 5.2.3 also use byte ranges

<jackjansen> silvia, so you expect 2 exchanges (for 522): one in bytes to get the header, then one in npt to get the video data. Correct?

<Yves> but if you got the data before, you might be able to do the mapping yourself and ask for bytes directly

<silvia> Yves, yes, it is playable: it assumes the UA already has all the information to do something useful with the byte range

<silvia> just as is the case with any other retrieval action that uses byte ranges

<silvia> jack: I am assuming the headers have already been received earlier

<Yves> it's playable if you have a-priori information about the data.

<silvia> it not, then yes, you need to get the headers first

<Yves> either you are mandating a specific container that have this characteristic, or you don't need this

<silvia> only for OGG, actually - MPEG doesn't need that

<silvia> Yves, with Ogg as it currently is, you cannot do the mapping yourself

<foolip> sure it does, MPEG doesn't repeat the headers over and over does it?

<foolip> at least not all versions

<Yves> fix the container!

:-)

<foolip> in any event: before spending lots of time trying to optimize away one network roundtrip, perhaps we should see if any implementor actually wants to solve this problem.

<silvia> foolip: MPEG actually does repeat the headers over and over :)

<jackjansen> Silvia, all newer formats have a header. So question is, do we do this work only for legacy formats?

<jackjansen> (header: I mean one that includes enough info to seek)

<silvia> Yves: we have fixed it and there is now a possibilty to put an Index into Ogg, which is why foolip said above that 5.2.2 will not be used very often

<foolip> silvia: even MPEG-4? always?

<silvia> 5.2.2 is only a minimal improvement over 5.2.1

<silvia> well, we've already done the work and it is a solution for any media format that has that problem, so I'd say we can safely leave it in the spec

OK

<silvia> foolip: IIUC yes, MPEG-4 has a way to do that, but you'd better ask Eric

I'm trying to summarize where do we stand

<foolip> I don't have a strong opinion, but would avoid spending time on it.

<silvia> 1. we need a decision that URI fragments always just retrieve a byte range and assume that the UA already knows how to decode that byte range

5.2.1: The UA is very clever, can do the mapping between seconds and bytes, send a Range request in bytes, almost no implementation is needed!

<silvia> 2. we need a decision if we want to remove 5.2.2 and 5.2.3 from the spec or leave it there for legacy formats

5.2.2: tiny optimiziation, the UA connot do the mapping, but there are still 2 requests, the first one, the UA got all the headers, the second one, the bytes of the data, the UA can play the file because of the first request with the headers, the Range request is expressed in seconds for example

<silvia> except that getting the headers will only happen once and for all subsequence fragment requests it will only be one request

5.2.3: has actuallly 3 exchanges, the first is the same than for 5.2.2 where the UA has requested the headers to be able to play the resource later on

OK, so go back to 2 points from Silvia

<silvia> 5.2.3 does what 5.2.2 does, but in a proxy-cachable manner

<Yves> my interpretation is that byte ranges should be good enough for anyone provided the container is ok, for clients that will do 2 or more requests to get the data

<silvia> i.e. the UA asks the server to send it the byte-range mapping and then does 5.2.1

<Yves> but it has latency issues

<Yves> the goal of having time ranges is to do everything in one exchange, to reduce latency

<Yves> 5.2.3 Proxy cacheable Server mapped byte ranges

<Yves> is actually doing 3 exchanges

<Yves> (but it's fine!)

<silvia> indeed, and this is why 5.2.1 will realistically be all that UAs do

Jack: Silvia is right, 5.2.2 is just for legacy formats, it has no value overall

<silvia> but there is optimisation along a different line for those that do 5.2.2: get proxy cachable requsts

Jack: we can keep it just mentionning that this is for legacy formats

<silvia> it already says so IIRC

<Yves> note that even when asked for bytes only, we can send a header to indicate the mapping to time ranges

<silvia> jut not in these words

<silvia> Yves, we could, but the UA already knows that, so why would be bother destroying cachability in this way?

<Yves> silvia, your solution for 5.2.2 is just helping bad container formats

<silvia> indeed :)

<silvia> for files that have been recorded live, getting an index is an extra effort

<silvia> and thus, some files will never have that header

<silvia> and I think that applies to both Ogg and MPEG

<silvia> so it's not actually as unrealistic as one might think

Raphael: Silvia, perhaps we should document the VERY first request for 5.2.2 and 5.2.3, the one where the UA got the headers of the media

Silvia, I agree, an action for you ?

I don't give it to you if do it now :-)

can you do a live edits to add this note?

<silvia> agree on both

<silvia> happy to make the change

ok, for the note, it is 2 min work

<silvia> will do both now

for the other, it will require more work ... including changing the figures, you want a formal action?

<silvia> I don't think we need to add a figure

<silvia> those two retrieval actions are independent of each other

<silvia> they may need to occur together, but if the UA already has the header, it will not need to do that first retrieval action

<silvia> so, I can just add a description of it and refer to 5.2.1 with some byte range from 0

<silvia> foolip: what byte range do you typically load for Ogg files?

Silvia, Yves objects on one thing (please listen)

<foolip> silvia: start from the beginning and load until we need to seek to the end, where we get 8500 bytes, then back to wherever data is needed next

Yves considers that 5.2.2 is useless and should be removed ... for legacy formats, 5.2.3 should be used

scribe: BUT, he sketchs another 5.2.2

<foolip> silvia: yes

<foolip> I know, we have an open bug for it :)

scribe: which is the original intention of the 2-ways handshake, where all data is sent

Jack is drawing on the board, pictures will come soon

Silvia, in 5.2.1, there is also this VERY first request to do, where the UA got the headers, so more things to add in the spec

scribe: do you think you can do that in the next hour? or would you need more time?

<silvia> I wonder about the result on 5.2.2

<silvia> I didn't make changes because I was waiting for Yves' proposal

<silvia> but maybe it's another proposal altogether and needs a 5.2.4 ?

<silvia> I will start working on 5.2.1 now

<Yves> 5.2.2 as it is is useless, for legacy container 5.2.3 should be used

<foolip> does the spec need to go into detail about what byte ranges may or may not be needed? it can't be normative anyway

<Yves> (server side mapping)

Sylvia, indeed, don't change 5.2.2 since Yves and Jack come with a new nice proposal

<silvia> I've adapted 5.2.1

<silvia> and committed :)

Silvia, the note for legacy format should go in the section 5.2.3, phrased slightly differently, where we said, legacy formats that cannot do the mappping (give examples, such as the old ogg file) need to use 5.2.3 description

<silvia> it's actually irrelevant to the spec where the UA gets the information from how to map the fragment to byte ranges - it could come from previously stored information or a previous retrieval action or from guessing - it doesn't matter

<silvia> so I just made that first paragraph more concrete

<silvia> raphael: I disagree that 5.2.3 is a requirement for legacy formats

<silvia> it is a possibility to use this, but not a necessity

ok silvia

<silvia> and also, you need a collaborating server, which will be hard to get

did you change the figures in 5.2.1 ? we are mainly looking at that :-)

<silvia> no, as I said: they don't need changing

<silvia> it doesn't matter where the information for the mapping comes from

<silvia> it's up to the UA to sort this out

<silvia> it could come from a index file that it was given by a third party server or anything else

<silvia> it could even just be guessing

<silvia> so, there is not necessarily an additional retrieval action

<silvia> also, 3.2 already describes different means of how the UA could get to that information

Silvia, the WG room thinks that it will be much clearer to add this information, and perhaps mark it specifically as header retrieval

scribe: the proof being the misunderstanding of some members beforehand

<silvia> there is no header retrieval for MPEG

<silvia> some formats just have an index somewhere

Philip: why did you remove the production of Segment? this is the hat on top of query and fragment!

<silvia> we have to describe the most general case, not just Ogg

<jackjansen> silvia, technically correct., but you will do an initial exchange

<silvia> not necessarily

<Yves> well you need to know the compression level

Exatly Silvia, that's why we think we should document how the information to be able to play the file has been obtained

<jackjansen> Silvai, and more generally I would like to concentrate on modern formats.

<silvia> I, the UA, may have received the information from a third party of how to map time to byte ranges

<silvia> it doesn't need to come through an extra interaction with this particular media resource

<Yves> so technically you request some bytes at the beginning, not file headers, just do have infrmation for doing the mapping

yes, but for clarity, we should write that down somewhere in the spec

and you could write that this info has been obtained from a third-party

<silvia> Yves: I do that for Ogg, yes

<silvia> but not for MPEG

<silvia> I wrote that the UA has somehow obtained this information and I wrote an example

<silvia> I don't think we need to add a graphic for it since, there are so many cases

<jackjansen> Silvia, how do you guess where to do your first seek, for (say) t=10,20?

Silvia, you agree that even in the case of MPEG, you need to know the compressiojn rate

<silvia> yep, could have been given to me in the HTML markup

<jackjansen> hmm, don't see that as a common use (but correct me if I'm wrong)

<foolip> jackjansen: bisection search, first guess is based on something like total size (bytes) amd total duration (seconds)

<silvia> there are proposals to put such information into the HTML spec

<silvia> if we write into the spec that a first retrieval action has to retrieve the resource headers, interpret them, and thus extract the mapping of fragment addressing to byte range, then we are severely restricting how this spec can be used

<silvia> we are prescribing something that people will need to ignore to actually make it work

<foolip> hehe, I would simply ignore the spec if it said something like that

<silvia> see :)

<foolip> in fact I will ignore *anything* the spec says with regards to what requests to make, when to look in the cache, etc

<Yves> there is an impact on latency

<silvia> Yves, nothing that HTML5 doesn't already have

<Yves> "I know just because it's a youtube URI that we have this format with this compression level" is a client-level hack that shouldn't be part of the discussion :)

<silvia> there is no extra latency for a media fragment URI

<foolip> yes, there is a latency problem, but I'd rather solve it with an index than by introducing special headers (which most headers won't understand)

<jackjansen> Silvia, we are not saying it *has to* do this. We're saying it is probably going to be the common case.

<silvia> which is what I described in words

WHich paragraph exactly Silvia?

<silvia> no need for a graphic that would imply it always has to be done

First one in http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-frag ?

<silvia> 5.2.1

<silvia> As described in section http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#URIfragment-user-agent, the most optimal case is a user agent that knows how to map media fragments to byte ranges. This is the case typically where a user agent has already downloaded those parts of a media resource that allow it to do or guess the mapping, e.g. headers or a resource, or an index of a resource.

<silvia> Yves, if the UA already has a copy of the media resource in its local cache from a previous retrieval action days ago, it won't do another request either

OK, we seem to agree Silvia (you win a lot today)

<silvia> it's hard work!

<silvia> 6 months!

scribe: but in the existing figure, shows that the UA has already the headers
... we have a nice drawing on board

<jackjansen> Suggestion: we add a little blob to the client timeline saying "header already available or not needed"

<silvia> it's not a information needed for playback of the fragment

<silvia> it's a mapping that is available

<silvia> fragment to byte range mapping already available

<Yves> we agree that header is bad usage of "enough information to do the mapping" :)

Yes Silvia, this is also what Davy who reads in your mind say

<silvia> excellent :)

<silvia> I trust Davy - he has implemented the bugger ;)

Jack, Yves: we change 5.2.2 to have just one round trip, similar to 5.2.1

scribe: the request is epxressed in seconds for example
... the server sends back a playable resource, the only question is whether the data parts contains the original headers of the media (that need to be changed by the UA) or new synthetic headers made by the serve
... this is not cachable by legacy caches
... it might be by future caches

Philip, you reply to me only?

<silvia> actually, your description of 5.2.2 is exactly what 5.2.2 is

<silvia> no headers included

<silvia> only one roundtrip, just like 5.2.1

<silvia> why should that fragment request contain a header when 5.2.1 doesn't ?

<Yves> it needs enough information to play the file

<silvia> just like 5.2.1, it already has set up the pipeline

<Yves> so in some cases it can have headers, in some other cases, not

<Yves> no, in 5.2.2 you MUST NOT need to have the information magically before doing the request

<silvia> life is so much easier if all fragment requests just map to byte range requests

<Yves> but it's not needed!

<silvia> why would 5.2.2 be different to 5.2.1 ?

<Yves> you have byte ranges for that :)

<Yves> 5.2.2 as it stands has no value at all

<davy> I agree with Yves

<Yves> handling legacy formats is 5.2.3

<Yves> handling legacy formats using server-based mapping is 5.2.3

<silvia> no, it's also 5.2.2

<silvia> 5.2.3 is an improvement over 5.2.2

<silvia> davy: why?

<Yves> handling legacy content through byte ranges is 5.2.1

<silvia> we haven't changed 5.2.2 yet

we are discussing it

you want to join on the phone ?

<silvia> ok ...

<Yves> but I agree that my vision of 5.2.2 might not be implemented _now_ (or ever :) ) but at least it has a value by reducing the latency and requiring only one exchange

<Yves> http://www.example.com/foo#t=10,20

<Yves> what do you know beforehand about this thing?

<Yves> => nothing apart that it may be a media fragment

Raphael: *new* 5.2.2 is different than 5.2.1 since we do not need to have the prior information of mapping the seconds to bytes or the original information to play the media

Silvia: it is another optimization

Yves: no, 5.2.3 has also (like 5.2.1) the same asumption than the UA has the information to play the media
... so 5.2.3 is the optimization of 5.2.1
... Range request always expressed in bytes

Jack: again, I see now the value of 5.2.2
... for example as follow on requests from the same media
... someone click on the timeline to request another segment, but does not request once more the headers

Raphael: I'm considerink asking Yves to write his new optimization in a section 5.2.4 and see later on if we can keep it or not

<silvia> I would be happy if we introduced a request type that just gets us the setup information

<silvia> then that plus the existing 5.2.2 would be what Yves is proposing now

<jackjansen> silvia, that will require two roundtrips again.

<jackjansen> silvia, I would suggest as 5.2.4 a request that gets us setup information PLUS data

Silvia, what this mean <silvia> I would be happy if we introduced a request type that just gets us the setup information ?

<silvia> jack is right: if we want to avoid a round trip, we need 5.2.4

<silvia> incidentally, I am not sure how much browser vendors care about one additional round trip these days ;)

<silvia> seeking on Ogg without an index typically requires several round trips (I've seen 7 and more) and that was bad, but once it was down to 3-4 it was acceptable

<scribe> ACTION: Yves to add a section 5.2.4 describing his new optimization [recorded in http://www.w3.org/2010/03/09-mediafrag-minutes.html#action04]

<trackbot> Created ACTION-154 - Add a section 5.2.4 describing his new optimization [on Yves Lafon - due 2010-03-16].

<silvia> should I make some changes to 5.2.2 then?

<silvia> as discussed before?

NO

Raphael: Attempt summary
... 5.2.2 = request expressed in npt, anwers sent back in bytes + Content-Range equivalent
... mandatory
... or not :-)
... 5.2.3 = server-based bytes mapping, redirect involve, cachable

<silvia> I think we can adapt the headers once Yves has done his 5.2.4 - we might want to harmonize

<Yves> no need to adapt, we just reverse the use :)

Raphael: 5.2.4 = unlike the 3 other cases, we DON'T need to obtain first the mapping information (reduce latency), request expressed in npt, content-range expressed in the same unit, and content-range equivalent is in bytes

ok ?

scribe: 5.2.4 is uncacheable for legacy caches, but might be cacheable with new ones

<silvia> 5.2.2 doesn't have the mapping either

Silvia, 5.2.2 has the mapping, otherwise, how the file is played since this information is not sent

<silvia> no, there is a difference between having the fragment to byte mapping and having the decoding pipeline set up

<silvia> if 5.2.2 had the mapping , it would be 5.2.1

Silvia, ok, i'm talking only about decoding pipeline set up

scribe: I'm not talking about the mapping, different terminology

<silvia> so, 5.2.4: unlike the other cases, doesn't have the decoding pipeline set up for the file yet and obtains with the request also the necessary background information (headers etc)

Yes silvia

<silvia> this reduced the retrieval action by one round trip

yes silvia

<silvia> now, let me consider the headers...

<silvia> I think we need an extra header that says: send me the setup info, too

<silvia> how else would the server know whether it has to just return the bytes or also the header bytes?

<silvia> and … how does the UA know which bytes are header bytes and which are content bytes?

<jackjansen> Feeling slightly confused for haviing to channel Silvia as well as myself:-)

<Yves> like a 'transcode unit' flag

<Yves> might be optional in range syntax

Raphael: indeed, we need to differenciate at the protocol level that 5.2.2 and 5.2.4 are different, most likely new headers?
... or different header syntax

<Yves> Range: t:npt 10-20;convert

<silvia> even if we ignored 5.2.2 and it use of HTTP header syntax: how would the server package the data in a way that the client knows it's just receiving the header info and some byte range later in the file?

Raphael: perhaps it is part of Yves's action when describing the new 5.2.4 making sure it does not collide with 5.2.2

<silvia> we also need to remember that we have defined that media fragments provide for a subpart of the main resource and that e.g. a player would display the full timeline

<Yves> silvia, through the CRE, or a new "here is data" paramter or header or whatever

<silvia> so, the reply needs to signal to the UA exactly what data belongs to what

<silvia> ok, I'll wait till you've written it

<silvia> I just want to make sure we are on the same page in that this is NOT a new, shorter resource

Raphael: the WG thinks we should have a new name that Content-Range-Equivalent

<silvia> that's what the query is for

<Yves> the goal is not to send synthetic headed (well, metainformation needed to DTRT), but the orignal one

<Yves> no, query is identifying new resources

<silvia> ok, cool

Silvia, in 5.2.4 you will still have the context, the full timeline of the original media

<silvia> this is where we may still need to discuss with Conrad ;)

<silvia> I'm cool with it

OK, proposal for new header names?

Proposal: Range-Mapping ?

This new header will be used in 5.2.2 and 5.2.4

scribe: in 5.2.2, Content-Ranges is expressed in bytes, and Range-Mapping in the unit of the original HTTP request
... in 5.2.4, this is exactly the other way around

<Yves> s/other way around/other way round/

scribe: that conflicts with Conrad's opinion who thinks we should not have the Range header used with another unit than bytes

Silvia, are we done with that?

scribe: we think we can have lunck break, demo time, tc reviews now

<silvia> are we calling it Range-Mapping?

are you against?

silence = approval :-)

<silvia> I honestly don't care :)

<silvia> but we didn't vote

<silvia> Content-Range-Equivalent was also just signifying the mapping :)

Proposal: Call the only new introduced header 'Range-Mapping'

<silvia> ok, I will make the change

Proposal: call the only new introduced header: 'Content-Range-Mapping'

<Yves> +1

<davy> +1 for Content-Range-Mapping

+1 for Content-Range-Mapping

<erik> +1 for 'Content-Range-mapping'

<silvia> +1

<Yves> +1 for "Content-Range-mapping"

<jackjansen> +0

Jack: I may have opinion on the syntax of this new header
... I have no opinion on the name

RESOLUTION: (pending no objection from Conrad+Philippe) A new header named 'Content-Range-Mapping' will be introduced, used in sections 5.2.2 and 5.2.4 at least, which purpose is to expressed a mapping of a Content Range between 2 units (e.g. bytes and seconds)

<silvia> note that 5.2.3 also uses Content-Range-Mapping to signal back to the UA which range the provided byte range maps to

<Yves> even 5.2.1 may use CRM

<Yves> as metainformation

Raphael: I agree with both remarks

<Yves> but it reminds me that we should probably add a Cache-Control: no-store=" least, which purpose"

<Yves> but it reminds me that we should probably add a Cache-Control: no-store="Content-Range-Mapping"

<silvia> Yves: if we used CRM in 5.2.1, that would destroy cachability, right?

<Yves> why?

<Yves> it's meta-information, nothing more

<silvia> because of the extra header

<Yves> and old caches will ignore it

<Yves> no, see the cache-control directive ;)

<Yves> "don't store the header"

<silvia> ok, so is 5.2.2 cachable then?

<silvia> I guess because we use the new fragment dimensions on the Range header, they are not?

Raphael: Conrad, I want to clarify one of your wrong asumption in one of your email for yesterday night
... you wrote, don't use comma separated value for selecting multiple tracks in the Content-Range headers
... but we can, since Content-Range header cannot be split

<Yves> http://www.ietf.org/rfc/rfc2617.txt (about the use of ',' in headers, and splitting)

Raphael: similar to Authorization
... so: "Content-Range: track audio1,audio2" will be valid
... hope it clarifies this objection you have

Yves: I will have some clarification about that from HTTPbis in our meeting in 2 weeks
... if this changes, I will warn you

Conrad, would you like an action to add your use case in the UC document?

<conrad> raphael, yes

<scribe> ACTION: davy to draw diagrams to include in the spec, similar to Yves's email, that shows which bytes from the headers and body of the media file are sent [recorded in http://www.w3.org/2010/03/09-mediafrag-minutes.html#action05]

<trackbot> Created ACTION-155 - Draw diagrams to include in the spec, similar to Yves's email, that shows which bytes from the headers and body of the media file are sent [on Davy Van Deursen - due 2010-03-16].

<scribe> ACTION: Conrad to add a "bandwidth conservation use case" [recorded in http://www.w3.org/2010/03/09-mediafrag-minutes.html#action06]

<trackbot> Created ACTION-156 - Add a "bandwidth conservation use case" [on Conrad Parker - due 2010-03-16].

<conrad> raphael, concerning the comma, i object more strongly to using Content-Range for that anyway :-)

Conrad, to use Content-range for track?

<conrad> ie. i prefer a new header for time ranges etc., for which comma and header combining is allowed

Conrad, you want Range and Content-Range only used with the bytes unit?

<conrad> raphael, to use Content-Range for bytes (no change to existing implementations) and to use a new header to advertise the time range of the representation

<conrad> raphael, yes

<Yves> 206 requires a CR

<Yves> s/CR/Content-Range/

<Yves> (or a multipart byterange, that contains Content-Range headers)

<Yves> in fact it's not even sure that we can do the range mapping in another header

<conrad> generally i would like us to specify things so that the responses are cacheable with existing proxies, and i think that is well possible

Conrad, see section 5.2.3

<Yves> yes, use byte ranges

<conrad> ok, will review

<scribe> ACTION: Silvia to propagate the changes in the spec document now we have the new header 'Content-Range-Mapping' [recorded in http://www.w3.org/2010/03/09-mediafrag-minutes.html#action07]

<trackbot> Created ACTION-157 - Propagate the changes in the spec document now we have the new header 'Content-Range-Mapping' [on Silvia Pfeiffer - due 2010-03-16].

Jack: I'm warning everybody that it is likely we go in LC with the non-possibility of combining dimensions in a fragment URI

<silvia> my action has already been done and committed

<jackjansen> s/in a fragement URI/in the HTTP protocol

close ACTION-157

<trackbot> ACTION-157 Propagate the changes in the spec document now we have the new header 'Content-Range-Mapping' closed

<foolip> raphael: why add them back?

<foolip> we cannot define the syntax in one single layer unless we can come up with the syntax for expressing "any string that after percent-decoding and decoding UTF-8 is equal to the unicode string x"

<Yves> WD

<silvia> Jack confused me :)

and then LC in June as expected

<foolip> Yves: can you explain what changes you want to revert and why?

<foolip> It is obvious that there is no common understanding of how things ought to work

<silvia> maybe he has a syntax

<foolip> that would be great, but I'd like to know or we'll just do this all over again later.

<Yves> I want to have generic syntax + serialization ones

<Yves> so for the URI serialization, it shouldn't contradict your algorithm

<foolip> ok, what is the generic syntax?

<Yves> basically, unencoded name=value

<foolip> unencoded?

<Yves> well, raw strings in utf-8

<Yves> I'll do that tonight

<Yves> probably by email first

<foolip> on the URI fragment/query component level the data is percent-encoded bytes, how can a generic syntax be in terms of something unencoded?

<foolip> is the mediafragment production I added not the generic syntax? even though we should perhaps rename it to something like namevalues to avoid confusion

<Yves> URI fragment/query is part of the URI serialization

<Yves> so it will be encoded

<foolip> Yes, sure

<foolip> but can that be expressed in declarative syntax?

<foolip> I just want to know that there is actually some change and not just putting back the old syntax which doesn't match what we want implementations to match against.

Raphael: I suggest Yves send by email tonight what he intends to change to finalize the discussion

3. Implementation Report

Raphael: we will first start with a demo from Davy

Davy: I will first show slides
... URL to be provided soon
... room laughing at the title
... " Development of a flash player supporting media fragments: frustrations and results"
... requirements: flash media frgaments player, could be used in any browser supporting Flash, communication with Ninsuna or any Media Fragments compliant server
... we want to finally play the media fragments in the UA
... how to integrate Flash video player with Media Fragments servers, 3 possible solutions

s/frgaments/fragments

scribe: 1st approach: trivial use of the Flash video component
... takes an input a URI pointing to a MP4 file
... problem: no possibility to change the HTTP headers, so does not work
... 2nd approach: use the HTTP communication component
... make use of URLLoader component, possibility to add/set HTTP headers
... problem: browsers only allow modifications of non-standard HTTP headers
... it might be different with JavaScript (Philip, HELP !!!)
... URLLoader and video component are not integrated
... workaround: save received byte stram in a file ... not possible in an AIR application, no progressive play possible
... IE, Firefox and Safari all show the same behavior, communication between the flash api and the browser, my parameters are blocked and the browser prohibit to change the standard HTTP header
... 3rd approach: write an own flash video component, take as input the URLLoader component, requires a huge effort
... or modify existing flash video component
... only possible with help from Adobe

Raphael: Philip, it would be very great if you could react on that, based on your experience with Opera, is this possible at all for a browser plugin to interact with the browser and change the HTTP headers
... e.g. a plugin that catchs up the media fragment URI syntax, and just send a bytes range request
... that is NOT possible for sure with a Flash component interacting with a browser according to Davy experiment

<foolip> No, it's not possible to add arbitrary HTTP headers, and as far as I know not any headers at all, not via the netscape plugin API at least.

Raphael: Davy said you can add non standard headers, you cannot modify the default ones!

<foolip> Perhaps flash has its own HTTP stack that completely bypasses the browser, or there is more to the netscape API than I have seen.

Davy: conclusion is in order to support Media Fragments, players MUST be modified

<silvia> foolip: XMLHttpRequest allows setting HTTP headers

Raphael: Silvia, can you override the ones from browser?

Davy: Media Fragments flash player

<silvia> raphael: yes

<foolip> silvia: Is that actually implemented by most browsers? In either case, this shouldn't be available to plugins.

Davy: able to play any mp4 file

<silvia> foolip: I don't know if plugins can use it, but you can write it in a Web page

Raphael: Philip, are you suggesting then that the code of the browsers will need to be modified?

Davy: demo = http://ninsuna.elis.ugent.be/MediaFragmentsPlayer

<foolip> I doubt it will ever be possible from plugins if it doesn't already work. I'm sure it doesn't work in Opera via plugins because byte ranges weren't very well supported before <video>

Raphael: Philip, then how do you think UA should become media fragment aware? Does Opera plan to change the browser code in order to generate Range request?

<foolip> We have already done it for <video>, supporting media fragments is just a matter of parsing a string and seeking to an offset (more or less)

<silvia> foolip: I think setRequestHeader is implemented by all browsers, even as early as this http://www.jibbering.com/2002/4/httprequest.html <- it is available

<foolip> silvia: XHR?

<silvia> yes, part of that

<foolip> then it isn't available to plugins (Flash), if that's the problem Davy had

Raphael: Philip, the whole point of Media Fragment URI is not to seek to an offset, but generate a Range Request to get portions of video clips

<silvia> http://en.wikipedia.org/wiki/XMLHttpRequest <- see setRequestHeader

<foolip> raphael: seeking is implemented with range requests, that's what I mean.

<foolip> internally it will be the same thing, with some fluff for the UI presentation perhaps and special behavior when looping

Raphael: philip, ok, thanks for the clarification, so I understand that we can use Javascript to simulate now new headers generation based on a parsing of the Media Fragment URI

<foolip> yes, that's possible today, but you'll get to see the first frame of the video for a while until the seek is finished.

<foolip> which the browser would hide in a native implementation

Raphael: and that browsers, such as Opera, will change their code to support media fragment?
... or am I hoping too much?

<foolip> I can't promise anything, it depends on our priorities and how sane we can get the processing of media fragments to be

Raphael: amazing demo from Davy

<foolip> (which is the reason I joined the group)

Raphael: supports already t, track and xywh dimensions !!!

<Yves> nice job, Davy!

Raphael: even the space dimension nicely rendered in the UA

<foolip> Yves: not really, I'd like the spec to be good as a whole too :)

<Yves> foolip :)

<foolip> to repeat, I don't care how things are defined as they allow sane implementation that allows future spec changes and progressive implementation.

<foolip> ... as long as ...

Raphael: I agree with this goal too :-)

Give it a try with http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4

scribe: we not have a cropping on only Silvia on the screen, all the rest is black
... spatial selection + temporal selection done

<silvia> take a photo!

Raphael: Philip, could you explain us WHY flash cannot set headers and Javascript can using the XMLHttpRequest

?

scribe: why browsers block one way and not the other way?

<foolip> I think there's just no API for it, but it's been a while since I looked at the netscape plugin API.

Raphael: pointing to http://www.jibbering.com/2002/4/httprequest.html

<foolip> I really don't know what Flash does, if it has a separate cache, if it bypasses the browsers HTTP stack, etc etc.

Jack: it is from 2002 !!!

Davy: yes, my code would also have worked few years ago
... the blocking is recent

Raphael: we are not sure we will not get blocked with Javascript either!
... we need to test

Silvia, do you follow tis?

s/tis/this

<silvia> Davy: did you try FlashXMLHttpRequest?

<silvia> http://blog.monstuff.com/archives/000294.html

<davy> no, that is another possibility to sort out

<foolip> In any case using XMLHttpRequest to get the video data sounds a bit... creative.

<silvia> it is - and only useful when you're trying to demonstrate the use without touching player code

Raphael: exactly :-)

<silvia> foolip: I'd much prefer you put native support into Opera!

Raphael: indeed Silvia, Philip the goal is to convince browsers vendors to change their code showing them prototypes, but we ALL prefer native support

<foolip> silvia: I'd like that too :) Still, I don't set the priorities so I can't make promises.

<foolip> The only reason I'm here is of course because I think doing MF is worthwhile.

<silvia> Davy: also make sure to take care of the crossdomain stuff, e.g. http://ejohn.org/blog/cross-site-xmlhttprequest/

Jack: I will have a look at having a pythong+Gstreamer implementation

s/pythong/python

scribe: similar to what Davy did client side but in python

<foolip> GStreamer :)

<mhausenblas> Michael: many excuses - system still seems not to work, can't dial in (but doesn't matter now as I have to drop in 15 min, anyway)

<guillaume> ref: http://lists.w3.org/Archives/Public/public-media-fragment/2009Aug/0004.html

<foolip> Is the room actually doing "Review all actions and issues and discuss / close as appropriate"?

<mhausenblas> Michael: My take on the TC would be - review them and I'll update then in the Wiki (see also http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0086.html)

ACTION-147?

<trackbot> ACTION-147 -- Michael Hausenblas to add all MF WG members to corrib -- due 2010-03-05 -- OPEN

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

<mhausenblas> yes, as I wrote - having issues with corrib; unsure if it is wise to continue with it

<jackjansen> michael, for the time being or forever?

<mhausenblas> well, depends on when I have some spare time to fix it, jackjansen ;)

<mhausenblas> I'd recommend to keep it in the Wiki for the time being

<mhausenblas> I can still add it to corrib later on

<mhausenblas> important action is to review them, now

Davy: I think corrib is a very useful tool for us, shame we cannot use it

<mhausenblas> Michael: agree with Davy

Michael, are you suggesting we just review all test cases, and the you take the burden to: 1/ update wiki pages, 2/ update corrib if this is necessary one day, etc. ?

<mhausenblas> yes, raphael

<mhausenblas> please just make sure that you do RESOLUTION: for each TC

<mhausenblas> so that I can point to it

Michael, can you show us the RDF generated by corrib ?

<mhausenblas> yes

is it somewhere in the group directory in cvs?

<mhausenblas> no

<mhausenblas> go to http://ld2sd.deri.org/corrib/

a url pointer?

<mhausenblas> click Dashboard ...

<mhausenblas> under export ...

<mhausenblas> http://ld2sd.deri.org/corrib/corrib.php?export=v1-mediafrag&format=rdf-xml

<mhausenblas> RDF/XML for example

<mhausenblas> but also in RDFa or via SPARQL endpoint

<jackjansen> Michael, is there an import as well?

<mhausenblas> not at the moment, jackjansen

<mhausenblas> but I planed to do it

<mhausenblas> worth an issue/feature request

<mhausenblas> http://bitbucket.org/mhausenblas/corrib/issues/

<mhausenblas> ok, chaps, sorry - gotta run now. will catch up later, reading minutes and anticipating some actions for /me

4. Test Cases review

Raphael: WG room made great progress in listing all test cases we want for the temporal dimension
... that makes 32 test cases
... 2 full boards, pictures taken, need to be filled within a table

<scribe> ACTION: Raphael to enter this big table in the wiki [recorded in http://www.w3.org/2010/03/09-mediafrag-minutes.html#action08]

<trackbot> Sorry, couldn't find user - Raphael

<foolip> are there test cases for e.g. #t=1&t=2, or #%74=%6ept%3A%310 ?

<scribe> ACTION: Troncy to enter the big table of all test cases for the temporal dimension in the wiki [recorded in http://www.w3.org/2010/03/09-mediafrag-minutes.html#action09]

<trackbot> Created ACTION-158 - Enter the big table of all test cases for the temporal dimension in the wiki [on Raphaël Troncy - due 2010-03-16].

#t=1&t=2 ... not yet, since we just did temporal dimension, syntax and semantic test, and not yet combination

#%74=10 is included

so #t=%31%30 is also

scribe: wait for the table to see that fully :-)

Oh, if the unit is %-encoded ... need to add these ones too

<foolip> ok, sounds good, we should be testing all kinds of weird input

yep

5. Wrap Up

Raphael: we need one more F2F meeting
... possibility in Raleigh with WWW, who can be there?
... Raphael, Davy, (Yves = no), (Jack = no?)

<foolip> Raleigh, North Carolina?

Raphael: Michael (likely)

Yes Philip, at WWW 2010, in April

scribe: Conrad and Silvia: not impossible

<foolip> oh, can't make it, I'm (very willingly) stuck in Beijing until June

Raphael: what are the other possibilities?
... Sophia Antipolis, host by Yves
... Hot topic net telecon

s/net/next

Erik: beginning of June may be the best time
... around June 10 ?

Raphael: I will send summary of today's meeting in few hours

[meeting adjourned]