demo · v138
Codec-specific orientation carriage
VP8, H.264, and AV1 have different bitstream mechanisms for orientation metadata. Chrome 138 exposes rotation and flip on VideoFrame, but an encode/decode path can preserve, normalize, or drop those fields depending on codec and backend. Run the roundtrip tests to see what this browser actually returns.
| Codec | Bitstream orientation slot | Container slot | What to verify |
|---|---|---|---|
| VP8 | None — no bitstream field | WebM RotationDegrees tag (optional) | Live decoded VideoFrame.rotation / flip |
| H.264 / AVC | No SPS field — SEI display orient. (opt-in) | MP4 tkhd transformation matrix | Live decoded VideoFrame.rotation / flip |
| AV1 | Metadata OBU (ITU-T T.35 / AOM) | MP4 tkhd or WebM tag | Live decoded VideoFrame.rotation / flip |
Click "Run roundtrip tests" to start.
// Chrome 138 exposes VideoFrame.rotation / .flip on source and decoded
// frames. Do not assume every codec/backend serializes those fields.
//
// The difference matters when SAVING to a file and re-parsing:
//
// VP8 (WebM): no bitstream field → orientation is in the WebM
// TrackEntry/Video/RotationDegrees element; lost if muxer omits it.
//
// H.264 (MP4): orientation goes in the tkhd rotation matrix or a
// SEI display-orientation NAL unit. Chrome's WebCodecs encoder
// does not currently write the SEI, so bitstream-level survival
// depends on the muxer writing the tkhd box.
//
// AV1: Metadata OBU can carry AOM-registered orientation.
// Whether Chrome's AV1 encoder writes it depends on the
// encoder backend version.
//
// Bottom line: inspect the decoded VideoFrame. Keep a container or JS
// sidecar value when your codec/backend normalizes the metadata.