Re: ABNF for fragment syntax

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
>>Deursen
>>Subject: Re: ABNF for fragment syntax
>>
>>On Wed, Mar 4, 2009 at 3:15 AM, Raphaël Troncy <Raphael.Troncy@cwi.nl>
>>wrote:
>>>>> Also, didn't we predefine things like track=audio at some point, or
>>did
>>>>> we drop that (and have I forgotten about it)?
>>>>
>>>> That is really a sub-part more than a fragment, we might address it
>>for
>>>> the identification of just the audio part (see discussion about
>>changing
>>>> 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
>>audio,
>>> 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?

Cheers,
Silvia.

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