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

Re: Describing recording by means of the Media Source interface

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 23 Aug 2012 19:17:04 +0200
Message-ID: <50366590.5030105@alvestrand.no>
To: Rich Tibbett <richt@opera.com>
CC: public-media-capture@w3.org
On 08/23/2012 07:10 PM, Rich Tibbett wrote:
> Harald Alvestrand wrote:
>> On 08/23/2012 06:52 PM, Josh Soref wrote:
>>> Rich wrote:
>>>> How is this not possible with the following existing pipeline:
>>>>
>>>> MediaStream -> HTMLAudioElement -> Web Audio API [1] -> WebSockets ->
>>>> ASR Service
>>> Technically, I think you can do something similar for video:
>>>
>>> MediaStream -> HTMLVideoElement -> HTMLCanvas.drawImage() ->
>>> HTMLCanvas.toDataURL()
>> at 30 FPS?
>>
>> The result would be akin to a Motion JPEG, only in PNG, I think...
>
> But that's the use case being requested in the Media Recording API 
> too, right? Except that you can't control how much data you get of how 
> many samples you take of the video per second.
That's where we need the constraints.... estimating how much data you 
get at a given framerate and resolution is pretty routine, once you know 
the codec.
>
> You can pull data from the canvas at whatever interval you like, less 
> than 30 times per second typically. You can also sample more or less 
> frequently depending on performance of course.
Motion JPEG, and even simpler schemes, is used on some USB cameras. One 
reason why HD cameras frequently use on-camera H.264 encoding is that 
simpler encodings create too much data for carrying over an USB 2.0 
interface.

The difference between the amount of data you need to handle for 
uncompressed video and compressed video is .... pretty dramatic.

Another thing you need, and don't get with these interfaces, is 
audio/video synchronization. That's a reason why the MediaSource spec 
talks about the WebM (Matroska) file format, not an audio stream or a 
video stream.
Received on Thursday, 23 August 2012 17:17:33 UTC

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