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

RE: recording proposal

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Tue, 16 Oct 2012 18:37:07 -0700
Message-ID: <E17CAD772E76C742B645BD4DC602CD8106DB5B90@NAHALD.us.int.genesyslab.com>
To: "Timothy B. Terriberry" <tterriberry@mozilla.com>, <public-media-capture@w3.org>
Though in scenario 3.5 (recording a conference call), there's not much
point in the recording if the various participants on the call (and also
people who weren't on the call) can't play it back.  

- Jim

-----Original Message-----
From: Timothy B. Terriberry [mailto:tterriberry@mozilla.com] 
Sent: Tuesday, October 16, 2012 9:29 PM
To: public-media-capture@w3.org
Subject: Re: recording proposal

Jim Barnett wrote:
> otherwise.)  On the other hand, unless we specify MTI container 
> formats, this approach doesn't provide much interoperability.  If we 
> want to avoid another round of the MTI wars,  maybe we could get away 
> with saying that the UA must support a container format that can 
> merge/synchronize a single video and single audio stream.  This would

MTI was viewed as important for the <video> tag so that websites could
encode files in a single format and serve it to all clients, and for
WebRTC so that two different clients could successfully communicate. The
case is somewhat weaker for recording, since (in the use-cases as I
understand them), the client is producing a stream for uploading to a
server, which will consume it once. I think the most important
requirement is that a browser produce a format that it can, itself, play
Received on Wednesday, 17 October 2012 01:38:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:12 UTC