[whatwg] On implementing videos with multiple tracks in HTML5

[Silvia Pfeiffer]

On Tue, May 1, 2012 at 2:27 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 20 Aug 2010, Silvia Pfeiffer wrote:
>>
>> Three issues I have taken out of this discussion that I think are still
>> open to discuss and potentially define in the spec:
>>
>> * How to expose in-band extra audio and video tracks from a multi-track
>> media resource to the Web browser? I am particularly thinking here about
>> the use cases Lachlan mentioned: offering stereo and surround sound
>> alternatives, audio descriptions, audio commentaries or multiple
>> languages, and would like to add sign language tracks to this list. This
>> is important to solve now, since it will allow the use of audio
>> descriptions and sign language, two important accessibility
>> requirements.
>
> I think this is now resolved. Let me know if there's still something open
> here.

Ha, yes! 21 months later and it's indeed solved through the same
mechanism that synchronisation of multiple audio/video tracks is
solved.


>> * How to associate and expose such extra audio and video tracks that are
>> provided out-of-band to the Web browser? This is probably a next-version
>> issue since it's rather difficult to implement in the browser. It
>> improves on meeting accessibility needs, but it doesn't stand in the way
>> of providing audio descriptions and sign language - just makes it easier
>> to use them.
>
> I'm not sure what you mean here.

It was the difference between in-band tracks and separate files. Also
solved by now.


>> * Whether to include a multiplexed download functionality in browsers
>> for media resources, where the browser would do the multiplexing of the
>> active media resource with all the active text, audio and video tracks?
>> This could be a context menu functionality, so is probably not so much a
>> need to include in the HTML5 spec, but it's something that browsers can
>> consider to provide. And since muxing isn't quite as difficult a
>> functionality as e.g. decoding video, it could actually be fairly cheap
>> to implement.
>
> I agree that this seems out of scope for the spec.

Thread closed. :-)

Cheers,
Silvia.