Guillaume (Jean-Louis) Olivrin
Davy Van Deursen
We can consider it is up to the container format to define the track names. We could recommend that there be a naming scheme such as video ... video[n] and audio ... audio[n] to address multiple a/v tracks, maybe even text ... 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.
Add notes (no markup allowed, URIs get automatically hyperlinked):
At the F2F in Barcelona it was discussed to leave the definition of standard names to a later version of media fragments. For now it should suffice that we allow container formats that are able to provide track references to address them in this way.
[conrad]: so i think we discussed not predefining lots of track names, but perhaps predefining "audio" and "video" only: in which case action 73 would be to change issue 4 to "Should we predefine track names for audio and video"