It encodes a single 640x480 all-zeros frame with VP8
and prints the IVF packet (a key-frame).

On a mouse click it sends the current video frame to VP8
and prints the generated IVF packets. If the frame hasn't
changed much, the output is a small 200-500 bytes delta.
If the new frame is very different, then the output is a 5-6 KB
key-frame.

Default VPX params:

   ?codec=vp8    Can also use vp9.
   ?width=640
   ?height=480

For example, to encode 720p video with VP9 use:

   ?libvpx=1&codec=vp9&width=1280&height=720

- Mouse click to encode the current frame.
- Ctrl+Click to decode it back to YUV.

YUV to RGB part isn't done yet.

Frames are either sent manually, at mouse click,
or by a timer if you add ?fps=10, for example:

...?libvpx=1&fps=5&width=480&height=360

Join the same room from two clients and use a
mouse click to start sending video. An attempt to
start video from the other side breaks the app:
currently encoder and decoder can't co-exist.

- In tab webrtc#1 join the room and then click to start sending video.
- In tab webrtc#2 join the room and then click to start sending video.

Video is received and decoded automatically, if the remote
peer sends it. However the local video is sent only on demand.

?fps=0 allows to send frames on demand.

1500 kbps is enough to send 720p video is good quality:
?width=1280&fps=30&height=720&vsbr=3000&libvpx=1

The max bitrate is limited by the max message size that
can be sent over RTCDataChannel: 64 KB. The frame
size will be about bitrate / fps.

Changing the bitrate doesn't seem to affect encoding or
decoding speed.

working capture

working capture

log to prove that it works

convert floats to ints

Experimenting

Fix bugs :P

Foo

…ted to transition to active