W3C home > Mailing lists > Public > public-media-fragment@w3.org > March 2009

Re: ABNF for fragment syntax

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 4 Mar 2009 18:20:24 +1100
Message-ID: <2c0e02830903032320i16fe53eu1463d264bd721313@mail.gmail.com>
To: Davy Van Deursen <davy.vandeursen@ugent.be>
Cc: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>, Yves Lafon <ylafon@w3.org>, Jack Jansen <Jack.Jansen@cwi.nl>, public-media-fragment@w3.org
On Wed, Mar 4, 2009 at 6:03 PM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
>>-----Original Message-----
>>From: public-media-fragment-request@w3.org [mailto:public-media-
>>fragment-request@w3.org] On Behalf Of Silvia Pfeiffer
>>Sent: Wednesday, March 04, 2009 12:58 AM
>>To: RaphaŽl Troncy
>>Cc: Yves Lafon; Jack Jansen; public-media-fragment@w3.org; Davy Van
>>Subject: Re: ABNF for fragment syntax
>>On Wed, Mar 4, 2009 at 3:15 AM, RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
>>>>> Also, didn't we predefine things like track=audio at some point, or
>>>>> we drop that (and have I forgotten about it)?
>>>> That is really a sub-part more than a fragment, we might address it
>>>> the identification of just the audio part (see discussion about
>>>> mime type for fragment/full sub-resources), but I don't remember if
>>we just
>>>> forgot, or if we dropped. Do someone remember?
>>> I remember we agreed to not predefine any track name, since we
>>couldn't find
>>> in the existing container format a coherent naming scheme for the
>>> video, etc. Davy, can you confirm?
>>track=audio doesn't make much sense. What if there are multiple audio
>>tracks? They all need to be named by the container format, so there
>>are no default names.
> I agree. However, in this context, one possibility is to provide a shortcut
> for the user to make a selection based on the media type, independent of the
> track name provided by the container format. Hence, media.mp4#track=audio
> would then be an easy way (i.e., without the need to know information about
> track names) to request only the audio track(s) within a given media file.
> The question remains how to deal with the situation of multiple tracks of
> the same media type: deliver all these tracks, deliver only the first, ...
> Do you think such a shortcut would be meaningful?

I would say that is really up to the container format to define. We
could recommend that there be a naming scheme such as video[0] ...
video[n] and audio[0] ... audio[n] to address multiple a/v tracks,
maybe even text[0] ... text[n]. But I don't think they make much sense
- it would be better the names chosen had some semantic meaning, such
as "video", "sign-language", "audio", "music", "speech",
"sound-effects", "audio annotations", "subtitles-en", subtitles-de",
"karaoke-en", "lyrics" etc.

 And .. yes, at some point somebody should have some standard names
for these - in particular for accessibility it would be nice to be
able to say through the protocol "I want no audio tracks, but video
and sign-language and all text tracks".

Maybe there is a scheme that we need to develop, where the codec type
is also part of the naming, e.g. video.sign-language,
audio.annotations, video.music etc. We haven't thought much about
structure for describing tracks yet.

What do people think?

Received on Wednesday, 4 March 2009 07:21:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:41 UTC