- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Jun 2023 20:41:50 +0000
- To: public-webrtc-logs@w3.org
> The input would be black frames no? Only for muted/enabled=false track. For null tracks, `If [track](https://w3c.github.io/webrtc-pc/#dom-rtcrtpsender-track) is null then the [RTCRtpSender](https://w3c.github.io/webrtc-pc/#dom-rtcrtpsender) does not send.` This paragraph seems to induce that black frames are sent for ended tracks. I am not sure browsers are doing this though (safari does not AFAIK except maybe if the track is muted/disabled while ended), we should check this. My understanding matches @fippo's understanding, the promise will resolve when a key frame is generated, which may be very long if the track is not outputting any frame (canvas capture say). For a null track, we can do whatever we want, the current behaviour will wait for a frame, which can only happen if an actual track is set via replaceTrack. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/185#issuecomment-1579418991 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 June 2023 20:41:52 UTC