Spec says to send black frames for ended tracks

[jan-ivar]

The spec says: "If track is ended, or if the track's output is disabled, i.e. the track is disabled and/or muted, the RTCRtpSender MUST send black frames (video) and MUST NOT send (audio). In the case of video, the RTCRtpSender SHOULD send one black frame per second. If track is null then the RTCRtpSender does not send."

This seems unequivocal: sender.track.stop() = send black frames!

Pity no browser is doing this. Try it (local video on the left, remote video on the right):

• Chrome:
• Safari:
• Firefox:

Ignoring the variance on the left (different issue), none of the browsers send black frames on ended.

Do we:

1. File bugs on implementations?
2. Or align the spec with implementations?

[jan-ivar]

Two observations:

• since the video on the left is the source of the video on the right, I'd expect stopping it to affect them the same
• remote participants seeing a still of the user while the user's self-view is blacked out seems surprising in a bad way

[youennf]

• since the video on the left is the source of the video on the right, I'd expect stopping it to affect them the same

I tend to agree, Firefox at least is consistent.

• File bugs on implementations?
• Or align the spec with implementations?

I am a bit reluctant to change what peer connection implementations are doing given they are all consistent. We should try to get browser interop for the local preview.

[eladalon1983]

Transmitted frames are not guaranteed to be received and decoded. Quality Web applications should robustly treat that edge case where the black frame does not arrive, and such treatment would likely obviate the black frame. Could we consider dropping this requirement altogether?

[dontcallmedom-bot]

This issue had an associated resolution in WebRTC December 2024 meeting – 10 December 2024 ([webrtc] Issue 3014: Spec says to send black frames for ended tracks):

RESOLUTION: Proceed with aligning with current implementations