W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2012

Re: recording proposal

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 17 Oct 2012 08:42:46 +0200
Message-ID: <507E5366.7070206@ericsson.com>
To: public-media-capture@w3.org
On 10/17/2012 02:48 AM, Timothy B. Terriberry wrote:
> Harald Alvestrand wrote:
>> If one tries to record something with multiple tracks onto a container
>> format that does not support them, failure is to be expected. But I
>> think some container formats can do this just fine (witness DVDs with
>> alternate camera angles). Subject matter expertise is needed here.
>> (I don't know the formats well enough.... I know it's possible to write
>> codecs in Javascript, but is writing a Matroska or DVI container
>> producer in Javascript something we expect people to do and get right?)
> Basically any container format can support an arbitrary number of
> tracks. That does not mean software which plays back those files will do
> so, however. In Firefox, for example, we always pick the first video and
> first audio track we recognize, and ignore the rest.
If I parse the html5 spec/media element correctly it says roughly:

* (resource fetch alg) when fetching a resource:
** mix all (enabled) audio tracks, play them
** play the first (enabled) video track

* (after fetch, during play): the app can change what audio tracks are 
mixed&played, and which video track that is played by fiddling with the 
"enabled" attribute on the media element's AudioTrack interface and the 
"selected" attr. on the media element's VideoTrack interface.

I take it that this is not what FF do presently. It would be interesting 
to discuss if you plan to update to follow the html doc (or if that doc 
should be changed); and we IMO need to discuss this for MediaStreams as 
well (I proposed that this should be on the agenda for TPAC).

Received on Wednesday, 17 October 2012 06:43:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:37 UTC