Issue of combining multiple dimensions

Hi all,

I finally read all the irc transcript from the last two days and the
issue of combining multiple dimensions stuck on me.
http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/16

I am assuming the issue is not how to combine the dimensions in the
URI, because that's easily done with combining name-value pairs with
"&". I assume the main issue was about how to encode it in HTTP
headers.

As discussed a long time ago, the id dimension can probably not easily
be combined with any other dimension. I am not even sure any more if
this dimensions makes much sense without specifying which "real"
dimension it refers to, i.e. if it's a name on the timeline, in the
spatial domain or a track. It obviously cannot be a track, since then
we would just use the track name. So, maybe it makes sense to extend
the named dimensions with a name-space hint, something like:
id:t=cool-scene or id:xywh=this_is_Raphael . Some more food for
thought...

So, let's look at combining the other dimensions.

In the URI query case, we can easily combine all the dimensions and
leave the resolution to the server, which will probably create a new
video with only the requested tracks included for the given time
interval and the cut out image region. That's what Ninsuna does now
and will always work.

In the URI fragment case, it's not actually that much more complicated.

We have said that the spatial dimension is resolved only locally,
nothing transported to the server. So, no issue there at all. Which
reduces the problem to combining the temporal and the track dimension.

We also only have to consider the issue for the 5.2.2 - 5.2.4 case
with HTTP headers, because in the case of 5.2.1, the user agent
already knows how to map both, the time and the track dimension to
byte ranges (which, incidentally, seems to be easy with
MPEG/QuickTime, but not with Ogg, where tracks are interleaved).

Thus, we need to look at specifying it in the "Range" request header
and the "Content-Range-Mapping" header.

According to RFC 2616,
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35, the
only currently available ranges-specifier is: ranges-specifier =
byte-ranges-specifier . Also, 14.35.2 says
"HTTP retrieval requests using conditional or unconditional GET
methods MAY request one or more sub-ranges of the entity, instead of
the entire entity, using the Range request header, which applies to
the entity returned as the result of the request" .

Thus, it is possible to specify one or more sub-ranges of the entity
(even though the ABNF doesn't allow for it ;-). Thus, IIUC, it is
possible to specify something like:
Range: range1
Range: range2

or Range: range1; range2

RFC 2621 unfortunately doesn't say anything about how the notation
should be, so either we have to ask somebody who knows or we can make
up our own?
Also, it is unclear if such a specification means that the ranges are
additional (i.e. all of range1 plus all of range2) or intersect (i.e.
all of range1 restricted to all of range2). I don't think that is
specified at this instant and I would ask Yves for clarification
there.

Depending on the answer to this, we will have to create a different
solution. Incidentally, if it's the intersect-meaning, then Conrad's
concerns on having byte ranges as well as other dimensions becomes
void, since it will just work.

In the case of intersect-meaning, we can specify the range headers as
defined in http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaFragmentHeaders,
simple as a sequence of Range headers:

Range: t:npt=10-20
Range: track=foo,bar
(and analogously: Content-Range-Mapping: t:npt 9.2-21.6/0-75 ; track=foo,bar)

If we have to deal with the additional-meaning, we could simply
combine all the fragment dimensions into one Range header to avoid the
additional-meaning, which means we can specify ourselves the
intersect-meaning on the one header, e.g.

Range: t:npt=10-20&track=foo,bar/0-75
(and keep: Content-Range-Mappping: t:npt 9.2-21.6/0-75 ;
track=foo,bar, since we can define on this header whatever we like.)

This may still conflict with Conrad's problem of combining byte ranges
with fragment ranges, so it may indeed be an idea to consider
introducing a new Range request header for this, if we really consider
Conrad's use case a valid one.

Anyway ... some food for thought to progress on this issue.

Cheers,
Silvia.

Received on Wednesday, 10 March 2010 00:27:10 UTC