[webrtc-encoded-transform] Spec does not define whether empty / no-data frames (e.g. padding) are delivered to a transform or dropped (#310)

Drekabi has just created a new issue for https://github.com/w3c/webrtc-encoded-transform:

== Spec does not define whether empty / no-data frames (e.g. padding) are delivered to a transform or dropped ==
### Summary

The spec does not say whether encoded frames with **no payload data** (zero-length / null `data`) are exposed to an `RTCRtpScriptTransformer`, nor what a transform is expected to do with them. In practice the RTP stack produces such frames — e.g. **padding**-derived frames — and it is currently unspecified whether these reach `transformer.[[readable]]` at all.

### Spec references

- [§2.1.1 *readEncodedData*](https://w3c.github.io/webrtc-encoded-transform/#abstract-opdef-readencodeddata) says, for every `frame`, to *enqueue frame into transformer.`[[readable]]`*, with no carve-out for frames that carry no data.
- [§2 *Specification*](https://w3c.github.io/webrtc-encoded-transform/#specification) states the UA *MUST invoke* `[[transformFrameAlgorithm]]` *"whenever the encoder outputs an encoded frame"* / on every received frame — again with no exclusion for empty frames.
- [§4.3 `RTCEncodedVideoFrame`](https://w3c.github.io/webrtc-encoded-transform/#RTCEncodedVideoFrame-interface) and [§4.5 `RTCEncodedAudioFrame`](https://w3c.github.io/webrtc-encoded-transform/#RTCEncodedAudioFrame-interface) define `.data` as an `ArrayBuffer`, but say nothing about whether it may be zero-length, and padding is not mentioned anywhere.

So the algorithms imply *"all frames are delivered"* but never define the boundary case of a frame whose `data` is empty (or whether padding counts as "an encoded frame" at all).

### Why this matters (interop + robustness)

1. **Interop divergence:** because delivery of empty/padding frames is unspecified, UAs are free to (a) deliver them, (b) silently drop them, or (c) coalesce them — and a transform that works in one browser can misbehave in another.
2. **Author hazard / DoS-like footgun:** the receive transform is in the audio critical path. A transform that assumes a non-empty payload and stalls/throws on a 0-byte frame can halt *all* playback for the stream, not just that frame. Conversely, dropping these frames is observably harmless to media (they carry no decodable payload and RTP loss accounting happens upstream of the transform).
3. **Implementation evidence:** we hit this in Gecko — no-data, padding-derived frames reached the receiver transform and caused the [`RTCEncodedAudioFrame-audiolevel.html`](https://github.com/web-platform-tests/wpt/blob/master/webrtc-encoded-transform/RTCEncodedAudioFrame-audiolevel.html) WPT to fail. Whether a no-data frame should have been delivered to the transform in the first place is exactly the unspecified behavior at issue.

### Questions to resolve

1. Are empty / no-data frames (e.g. padding) intended to be enqueued into the transformer's readable, or filtered out by the UA before [§2.1.1 *readEncodedData*](https://w3c.github.io/webrtc-encoded-transform/#abstract-opdef-readencodeddata)?
2. If they *are* delivered, must `data` be a (valid) zero-length `ArrayBuffer`, and what `type`/metadata should they carry so authors can recognize and pass them through?
3. Is RTP padding considered "an encoded frame" for the purposes of [§2](https://w3c.github.io/webrtc-encoded-transform/#specification) at all?

### Possible resolutions

- **Filter at the UA:** normatively state that the UA does not enqueue frames that carry no codec payload (e.g. padding), so transforms only ever see real encoded frames.
- **Deliver but specify:** require `data` to be a zero-length `ArrayBuffer` (never null), define the `type`/metadata for these frames, and add author guidance that transforms must forward frames they don't understand unchanged.

Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/310 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 4 June 2026 03:24:15 UTC