demo · v136
Encoder round-trip
The explainer's blunt warning: "encoding may silently encode incorrectly." Build a VideoFrame with a chosen rotation, encode it with VideoEncoder, decode the chunk back with VideoDecoder, and check whether the decoded frame still carries the same orientation. Pre-136 the orientation was lost between encode and decode.
1. source canvas
2. input VideoFrame
3. decoded output
step log
—
the code
const enc = new VideoEncoder({ output: chunk => decoder.decode(chunk), error: console.error });
const dec = new VideoDecoder({ output: f => {
console.log(f.rotation, f.flip); // 136+: matches the input frame
f.close();
}, error: console.error });
await enc.configure({ codec: "vp8", width: 320, height: 240 });
await dec.configure({ codec: "vp8" });
const inFrame = new VideoFrame(canvas, {
timestamp: 0,
rotation: 90,
flip: true,
});
enc.encode(inFrame);
inFrame.close();
await enc.flush();why this angle
The sibling concept shows the simple construction case — "set rotation on the frame, paint it, see the rotation honoured." That's a single API surface (constructor + drawImage). This concept exercises the other half of the contract: that the metadata survives the codec pipeline. The chromestatus explainer specifically calls out container metadata (Android cameras, mp4) and encoder paths as the failure mode that motivated the feature, so it deserves its own page that actually runs encode/decode and asserts the round-trip.