Should a muted video track be allowed to deliver black frames to its sinks?

[youennf]

The specification is describing what mute means here:
Live samples MUST NOT be made available to a [MediaStreamTrack](https://w3c.github.io/mediacapture-main/#dom-mediastreamtrack) while it is [muted](https://w3c.github.io/mediacapture-main/#track-muted).

From this definition, it is clear that, whenever a track is said to be muted, it is not expected to provide black frames to any of its sink.
This is JS observable, for instance via rvfc or MediaStreamTrackProcessor.

But the specification also says that:
The result for the consumer is the same in the sense that whenever [MediaStreamTrack](https://w3c.github.io/mediacapture-main/#dom-mediastreamtrack) is muted or disabled (or both) the consumer gets zero-information-content, which means silence for audio and black frames for video.

This might have confused some readers/implementors to think that it is ok to have a live muted track provide black frames to its sinks.
My understanding of the intent of the spec is that sinks should handle the muted signal themselves.
For instance:

1. video elements should render black. No need for the track to provide black frames.
2. peer connection should periodically send black frames. Again no need for the the track to provide black frames to the peer connection.

That would mean rvfc or MediaStreamTrackProcessor would not receive any black frame from a muted track.

[youennf]

The same question can be asked for enabled=false tracks.
Testing on Chrome and Safari with https://jsfiddle.net/9o57mxg8/, it seems both expose that frames are delivered to the video elements on rvfc (drawing to canvas and probably creation of video frames lead to black).