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

Re: About video & audio elements

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 13 Oct 2008 23:34:43 +0000 (UTC)
To: "public-html@w3.org WG" <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0810132312430.1237@hixie.dreamhostps.com>
On Mon, 25 Aug 2008, Henri Sivonen wrote:
> On Aug 25, 2008, at 14:48, Ian Hickson wrote:
> > > 
> > > - In a browser vendor way of thinking, load the prefered tracks for 
> > > the user (after he selected his prefered listening/reading languages 
> > > in his browser's prefs)
> > 
> > The user agent would be expected to remember the user's language 
> > preferences and select the preferred track from the media resource.
> 
> Making translation subtitle selection automatic (as opposed to exposing 
> same-language captioning for the deaf) is a non-trivial problem when 
> users aren't monolingual. It's not too unusual for people to accept 
> audio in a couple of languages without subtitles but prefer subtitles 
> for one of them in difficult cases and to also accept subtitles in a 
> couple of languages but to wish to avoid them when unnecessary. 
> Especially it would be hard to create configuration UI that is simple 
> enough for users to use (and thus content providers could rely on the 
> selection mechanism to do the right thing) and that would at the same be 
> smart enough to choose the right subtitles without annoying users all 
> the time.
> 
> It seems to me that this feature has an unfavorable cost/benefit ratio 
> in terms of UI complexity cost vs. benefit from not requiring users to 
> choose subtitles from on-page UI each time, so I wouldn't make any plans 
> with the expectation that this kind of feature would get implemented, 
> working and popular.

I don't really follow. Computer DVD player software seems to manage fine. 
It remembers the language that I last used, and whether I last had them on 
or off, and just keeps that setting. If I change it, which is just a 
matter of picking a language from a list of available languages, it 
remembers that instead.



On Mon, 25 Aug 2008, 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)
> 
> 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.

Indeed.


On Thu, 28 Aug 2008, Maurice wrote:
> On Aug 25, at 7:48 AM, Ian Hickson wrote:
> > > 
> > > - What about multi-tracks files ? (For instance a video with a 
> > > French and English audio tracks and German and Japanese subtitles)
> > 
> > This is supported if the media format supports it. No API exists 
> > currently to expose this to script, however.
> 
> What about separate files for sub-titles? In the fan-subbing scene it's 
> common for videos to be distributed without any subtitles and then many 
> people around the world do their own translation and share the text 
> files with the web.

There's no support for external metadata files, but the way one would 
expect to do this is to merge the files first (e.g. using SMIL) and then 
to use that as the video file.


> > > > - In a search engine way of thinking, and still for these 
> > > > multi-tracks files, how could we parse an HTML document to get all 
> > > > the availables tracks (maybe a available-audio attribute ?)
> > > 
> > > Right now there is no way to do this other than actually examining 
> > > the media files.
> 
> There are server side libraries for pulling all the info you could ever 
> want out of video and audio files. What would be the best way to present 
> this meta data for search engines?
> 
> * attributes on the video tag?
> * <mediadetails> tag within the video tag?
> * some new microformat?

Why not just let the search engine read the video file?


> > > - In a browser vendor way of thinking, load the prefered tracks for 
> > > the user (after he selected his prefered listening/reading languages 
> > > in his browser's prefs)
> > 
> > The user agent would be expected to remember the user's language 
> > preferences and select the preferred track from the media resource.
> 
> 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?

I wouldn't recommend this approach. Better to use something like SMIL or 
sync them explicitly, and then use that as a the "video" file in the 
<video> element.



On Fri, 29 Aug 2008, Nicolas LE GALL wrote:
> 
> I think examining the media files will cause too much problems :
> 
> - Making an algorithm to parse the media header to retrieve the metadata 
> (depending on the codec used the header can have a variable size  just 
> presuming)
>
> - For the media provider it will consume some brandwith which is the 
> most expensive charge (at this moment)
>
> - I think parsing a media file cost more computer resources than parsing 
> an HTML document
>
> - Need a soft to edit the data (OK, you definetly need a soft to 
> encode... But if you made a mistake editing some HTML 
> attributes/elements is lighter than opening the media in a soft, editing 
> it and uploading it again)

Splitting the metadata up from the video, however, leads to wrong data on 
the long run, which is far worse a cost than any of the above.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 13 October 2008 23:35:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:58 UTC