RE: Track fragments

Hi Silvia,

On feb 16, 2010 at 13:00, Silvia Pfeiffer wrote:
> Cc: DENOUAL Franck; public-media-fragment@w3.org
> Subject: Re: Track fragments
> 
> Hi Davy,
> 
> On Tue, Feb 16, 2010 at 7:04 PM, Davy Van Deursen 
> <davy.vandeursen@ugent.be> wrote:
> > On feb 15, 2010 at 22:23, Silvia Pfeiffer wrote:
> >
> >> It is possible do devise a track addressing method that includes
> some
> >> of the other attributes. For example, a combination of type, role
> and
> >> lang could make sense, something like:
> >>
> >> #track=audio(audesc, en)&video(main,en)&text(cc,en)&text(sub,fr)
> >>
> >> I just made this up, so feel free to suggest any other markup means.
> >
> > So 'audio(audesc, en)&video(main,en)&text(cc,en)&text(sub,fr)'
> > corresponds to the trackname?
> 
> Nah, I did indeed mess this one up. "&" should not have been used 
> here, since it separates name-value pairs. You've used semicolon to 
> separate your track names, so this would be more appropriate:
> 
> #track=audio(audesc,en);video(main,en);text(cc,en);text(sub,fr)
> 
> and this would imply that the media resource has basically named the
> tracks:
> * audio(audesc,en)
> * video(main,en)
> * text(cc,en)
> * text(sub,fr)
> 
> They could just as well have been named
> * a1
> * v1
> * t1
> * t2
> or anything else, but the idea is to explore if some scheme can be 
> found that helps addressing rather by features of the track than by a 
> generic name. I think this was what we meant by "default names".
> 
> 
> >> One thing I need to add to this discussion is that track addressing 
> >> with *URI fragments* may be less about addressing and more about 
> >> activating. So, it interrelates very closely with the JavaScript 
> >> API, which is why I am waiting for that to stabilise and have some
> initial
> >> implementations. This is certainly different if we use URI queries
> >> (?) for addressing, since then we compose a new resource with just 
> >> the requested tracks.
> >
> > Do you mean by 'activating' that the server typically sends all the 
> > tracks to the UA? If so, than this might cause (bandwidth) problems 
> > when multiple video tracks are present within the media resource ...
> I
> > don't see any difference between track and time fragments within the 
> > discussion of ? vs. # (do you?), so I think that track addressing
> with
> > URI fragments is really about addressing :-).
> 
> The biggest issue with addressing tracks is that they tend not to 
> easily map to byte ranges - at least not to a small number. In fact, 
> they tend to map to a large number and it is almost impossible for the 
> client to know which byte ranges belong to which track (at least 
> within Ogg).

Hmmm, I do agree that track selection results in large number of byte ranges
(on condition that the tracks are interleaved). But I don't see the reason
why this would be hard for the client to manage the mapping between track
and byte ranges. Temporal fragments can also result in multiple byte ranges,
Ogg doesn't have a problem with that though?

> 
> How did you implement it in NinSuna? Did you use "?" to compose a new 
> resource with the restricted number of tracks or did you use byte 
> range requests?

Currently, the front-end in NinSuna uses the '?' to address track fragments.
However, the underlying implementation is based on byte range selection.
More specifically, a request such as http://example.org/media.ogg?track='ex'
will trigger the following actions:
- get the list of byte ranges corresponding to the fragment request
- create the headers of the container format
- copy and add all the obtained byte ranges to/after (depending on the
format) the headers

Best regards,

Davy

-- 
Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems - Multimedia Lab
URL: http://multimedialab.elis.ugent.be/dvdeurse

Received on Tuesday, 16 February 2010 15:36:43 UTC