W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2018

API proposals for raw data - 1 - Introduction

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 29 May 2018 08:27:39 +0200
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <b9f446de-c99c-69dd-7faa-63e7b8f7ff9a@alvestrand.no>
**

*This is part 1 of a multipart posting*, *laying out various API ideas
in response to the need for "raw data access". *

*

Problem:


Many creative usages of WebRTC audio and video data require direct
access to the data - either in raw form or in encoded form.


All of these things are possible today, but they are not simple.


The current interfaces to get raw samples are:

  *

    Use WebAudio to generate samples as arrays of floats in WebAudio’s
    clock (example
    <https://webrtc.github.io/samples/src/content/getusermedia/volume/>)

  *

    Use Canvas to paint from a <video> tag (example
    <https://webrtc.github.io/samples/src/content/getusermedia/canvas/>)

For injecting raw data we have:

  *

    Use WebAudio to generate a MediaStreamTrack from raw audio data

  *

    Use canvas.captureStream() to capture frames from a Canvas (example
    <https://webrtc.github.io/samples/src/content/capture/canvas-video/>)

For getting encoded data we have:

  *

    MediaRecorder (example
    <https://webrtc.github.io/samples/src/content/getusermedia/record/>)

For injecting encoded data we have:

  *

    MSE feeding a <video> tag, and then generating a MediaStreamTrack
    from the <video> tag



All of these mechanisms are somewhat convoluted, they impose
restrictions on the form of data that can be delivered (often imposing
transcoding costs), and require the application writer to be familiar
with multiple shapes of API surface.


A simpler method is desirable.

*

-- 
Surveillance is pervasive. Go Dark.
Received on Tuesday, 29 May 2018 06:28:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:41 UTC