RE: [rtcweb] Proposed text for local recording use case

Cullen,

In principle, copying real-time media to JS would certainly be a very flexible solution. However, depending exactly what the JS wants to use it for, I suspect there might possibly be performance issues.

Would there also be a requirement for passing media data from JS back down to the browser for transmission to the remote browser? I am thinking in particular of warning tone/announcements when recording is taking place, but of course it could be used for whatever you want.

The concept of passing media data up to JS / down to the browser would also be a solution for remote recording (if we decide we need it). The JS could then pass the collected data back down to another PeerConnection object for sending to the remote recording device. This in particular would need to be considered from a performance point of view - would passing it up to the JS and back down again be potentially slower than passing it between objects within the browser?

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: john.elwell@siemens-enterprise.com
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.


> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com] 
> Sent: 23 August 2011 22:57
> To: Elwell, John
> Cc: rtcweb@ietf.org; public-webrtc@w3.org
> Subject: Re: [rtcweb] Proposed text for local recording use case
> 
> 
> On Aug 22, 2011, at 8:42 AM, Elwell, John wrote:
> 
> > 4.2.xx Local Session Recording
> > In this use case, the web application user wishes to record 
> a real-time communication locally, such that transmitted and 
> received audio, video or other real-time media are stored in 
> one or more files. For a given medium, the two directions of 
> transmission can be stored in the same file (mixed) or in 
> separate files. The web application also stores metadata that 
> gives context to the stored media.
> > 
> > New requirements:
> > Fxx1: The browser MUST be able to store transmitted and 
> received media in local files.
> > 
> > Axx1: The web application MUST be able to ask the browser 
> to store transmitted and received media in local files, and 
> in the case of audio at least, ask for the two directions of 
> transmission to be stored mixed or separately.
> > 
> > John
> 
> I think I want something just slightly different and that is 
> to send media that is data in the JS and to be able to hand 
> media as data to the JS. If the JS happens to read / write 
> that to a file that is fine with me but this allows the JS to 
> operate on the data or synthetically generate media and opens 
> the doors to the possibility of writing a codec in JS or NACL.

Received on Wednesday, 24 August 2011 08:51:45 UTC