W3C home > Mailing lists > Public > public-html@w3.org > September 2008

Re: About video & audio elements

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Mon, 01 Sep 2008 17:04:10 +0200
Message-ID: <48BC046A.8080407@lachy.id.au>
To: Maurice <maurice@thymeonline.com>
Cc: Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>, me@neovov.com, Geoffrey Sneddon <foolistbar@googlemail.com>

Maurice wrote:
> What if I actually have a single video (no audio) and multiple audio 
> files, each in a different language. Could I somehow sync the video 
> and selected audio file by having them start playing simultaneously?

One option would be to mux all the audio tracks into the same container 
as the video track, which provides all the necessary syncing ability 
already.  I *do not* think it's a good idea to try and reinvent this in 
HTML by providing the ability to link to separate audio and video files 
and having them play in sync.

Although, if you have a lot of alternative languages, muxing them into a 
single file might significantly increase the size of the video download 
and you may wish to provide individual containers, each with the video 
track and one of the audio tracks.

With the latter approach, letting the user choose which language is as 
simple as linking to the appropriate video file. With the former, it 
depends on the UA providing some sort of UI to select the language.  But 
if use case of providing multilingual videos like that becomes popular, 
we could possibly look into providing a DOM API or other solution for 
language selection and allow page authors to provide custom UI in the 
page for it.

Geoffrey Sneddon wrote:
> On 25 Aug 2008, at 12:37, Nicolas LE GALL wrote:
>> - Is there any DRM support planned ? (I'm not asking for all 
>> video/audio to be signed, but I know a bunch of company who will 
>> prefer some proprietary technologies like Flash and his H.264 codec 
>> who support DRM than a semantic element which improve their Google 
>> rating)

No, and there never will be.  Henri has previously described the legal 
implications in relation to requests for other forms of technological 
protection measures before:


> There's nothing stopping a container/codec with DRM from being used 
> right now. I presume Saf 3.1/OS X plays FairPlay encrypted files right 
> now. The spec can never require any DRM encrypted format to be used, as 
> that would mean the DRM format being openly documented, making it 
> entirely useless.

That wouldn't work because each user needs to have a FairPlay licence 
key for the media on their computer.  It works for the iTunes store 
because the file is encrypted individually for each customer, rather 
than distributing exactly the same unmodified, encrypted file to 
everyone.  Of course, it's also totally ineffective since the decryption 
key is stored on the users system in a mildly obfuscated file.

The only type of DRM that could hypothetically work for websites would 
be somewhat like the DRM employed by Microsoft's EOT files, which is 
really little more than an ineffective obfuscation technique with 
various usage policies enforced by the browser.

Lachlan Hunt - Opera Software
Received on Monday, 1 September 2008 15:04:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:37 UTC