- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 4 Mar 2009 22:08:53 +1100
- To: Raphaël Troncy <Raphael.Troncy@cwi.nl>
- Cc: Davy Van Deursen <davy.vandeursen@ugent.be>, Yves Lafon <ylafon@w3.org>, Jack Jansen <Jack.Jansen@cwi.nl>, public-media-fragment@w3.org
On Wed, Mar 4, 2009 at 8:21 PM, Raphaël Troncy <Raphael.Troncy@cwi.nl> wrote: > Dear Silvia, > >> 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? > > It may be beyond our charter, but I think it is definitively something that > is worth to note, investigate if not bring a solution. Silvia, what about > creating an issue in the tracker recording exactly your message? Hmm, please do if you think it's worth it. I don't quite know how to go about it. Thanks, Silvia.
Received on Wednesday, 4 March 2009 11:09:32 UTC