W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] Stream API Feedback

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Thu, 17 Mar 2011 10:09:08 +0100
Message-ID: <4D81CFB4.9030703@lachy.id.au>
On 2011-03-17 04:22, Robert O'Callahan wrote:
> On Thu, Mar 17, 2011 at 4:36 AM, Lachlan Hunt<lachlan.hunt at lachy.id.au>wrote:
>
>> I'm not entirely sure I understand your proposal, but are you suggesting
>> that the input streams from the camera/microphone would first go to<video>
>> and<audio>  elements, allowing the existing HTMLMediaElement API on those
>> elements to be used to control those streams, the output of which can then
>> be encoded and recorded to a file or streamed remotely?
>
> Yes.
>
>> In fact, of all the properties that are on HTMLMediaElement, the only ones
>> that seem to have any real use for streaming media are volume, muted, paused
>> and ended.  So I'm not convinced that it's a good idea to try and reuse
>> existing APIs simple for the sake of reusing them, when they aren't really a
>> good fit.
>
> As Olli said,<video>  and<audio>  are designed to support streaming media;
> streaming over a low-latency network is very much like streaming from a
> local device.

Yes, for playback, that's fine, and that's what we've already 
implemented in our experimental implementation of the device element. 
But you seemed to be suggesting that it was sufficient for the purposes 
of controlling and encoding the video stream, despite the fact that 
those controls are not at all suited to that.  Such control needs to 
occur before the video element in the chain, not after it.

----------     -------------------             -----------
| Camera | --> | GeneratedStream | --+-------> | <video> |
----------     -------------------   |         -----------
                                      |
                                  ---------     -----------------
                                  | Codec | --> | Recorded blob |
                                  ---------     -----------------
                                      |
                                      |         ------------------
                                      +-------> | PeerConnection |
                                                ------------------

The stated of the stream, in terms of what gets streamed over P2P or 
recorded locally, must be controlled at the GeneratedStream and given as 
input into the codec.  This includes things like controlling the input 
microphone volume, video height and width, etc.  In particular, the 
encoded height and width for streaming may differ significantly from the 
rendered height and width in the local video preview, so this is not 
something that can be controlled by the video element itself.

> In Gecko, we allow seeking within cached segements of streamed video, and we
> could easily allow that for local devices too --- user-controlled "instant
> replay".

We don't buffer any streamed data in our initial device implementation 
and seeking is not possible.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Received on Thursday, 17 March 2011 02:09:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC