Is it expected that RTCRtpScriptTransform doesn't receive frames when H.264 decoder is unavailable?

[Rychou Wei]

Hi all,

On Android Chrome, when H.264 hardware decoding is disabled via chrome://flags, I noticed that RTCRtpScriptTransform / createEncodedStreams() never receives encoded video frame callbacks.

Looking at the W3C Encoded Transform spec, the transform sits between the depacketizer and the decoder:

RTP → Depacketizer → [Transform] → Decoder → Renderer

The spec says [[frameSource]] is the depacketizer, not the decoder. So even without an H.264 decoder, the transform should still receive encoded frames.

Is this expected behavior, or is this a spec compliance gap? 

Thanks!

[Philipp Hancke]

Am Do., 25. Juni 2026 um 06:12 Uhr schrieb Rychou Wei <rychou...@gmail.com>:

Hi all,

On Android Chrome, when H.264 hardware decoding is disabled via chrome://flags, I noticed that RTCRtpScriptTransform / createEncodedStreams() never receives encoded video frame callbacks.

Looking at the W3C Encoded Transform spec, the transform sits between the depacketizer and the decoder:

RTP → Depacketizer → [Transform] → Decoder → Renderer

The spec says [[frameSource]] is the depacketizer, not the decoder. So even without an H.264 decoder, the transform should still receive encoded frames.

Is H264 even negotiated in the SDP by the browser in that case?