RE: ACTION-178: Review the complete document, remove unnecessary editorial notes before publication (Media Fragments Working Group)

Hi Silvia,

> -----Original Message-----
> From: public-media-fragment-request@w3.org [mailto:public-media-
> fragment-request@w3.org] On Behalf Of Silvia Pfeiffer
> Sent: dinsdag 22 juni 2010 6:18
> To: Jack Jansen
> Cc: raphael.troncy@eurecom.fr; Media Fragments Working Group WG
> Subject: Re: ACTION-178: Review the complete document, remove
> unnecessary editorial notes before publication (Media Fragments Working
> Group)
> 
> On Tue, Jun 22, 2010 at 9:01 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>
> wrote:
> > On Tue, Jun 22, 2010 at 8:07 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
> >>
> >> On 21 jun 2010, at 15:49, Silvia Pfeiffer wrote:
> >>
> >>> 5. Clarify "track" dimension
> >>> I am rather confused right now: how did we decide to do multiple
> >>> tracks? In some places we talk about several tracks being able to be
> >>> defined, but only a single track per spec (see 4.3.3 and the
> >>> examples), and in other places we talk about there only being one
> >>> track dimension allowed (D.2 3c and 5.1.2, 5.1.2.1). Can somebody
> >>> clarify?
> >>
> >> We decided on multiple tracks recently (I actually seem to remember
that
> you suggested it,  because your contacts said that single-track-selection
> would be useless). But, indeed, most of the text was written when we still
> thought of single track selection only.
> >
> > Yes, multiple tracks. But how? Through multiple track parameters or
> > through one with semicolon-separated elements? I cannot remember
> > whether we made an actual decision on that. Once somebody clarifies
> > this for me, I can fix it either way. I would personally prefer them
> > all in one track parameter, since that will make the different
> > dimensions more consistent.
> 
> I think this example from Ninsuna suggests also that we will put multiple
> tracks in one track param:
> http://ninsuna.elis.ugent.be/DownloadServlet/mfwg/fragf2f.ogv?track=ogg
> _1;ogg_2

Currently, we indeed represent multiple tracks through one track param, both
at server-side through query parameters and at client-side (i.e, the Media
Fragments Player) through URI fragments. Note that representing multiple
tracks through multiple track params introduces difficulties when we use
query parameters, since the server will only interpret the first occurrence
of a track param ... So I would vote for combining multiple tracks into one
track param.

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, 22 June 2010 05:58:32 UTC