- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Feb 2023 09:20:07 +0000
- To: public-webrtc-logs@w3.org
I had some more thoughts about this. If the corresponding rid encoding is not active, or if sender is not sending at all (track is null or transceiver current direction is receive only), we probably want to reject. We do not want to resolve the promise until this check is done, but this check will be done in parallel, close to the encoder for both requestKeyFrame variants. That removes the possibility for resolving the promise as soon as getting a key frame for one of the given rid in the transformer case. Or we would need to wait for the check result to actually start looking at key frames, which is probably not worth the extra work. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/pull/165#issuecomment-1413398387 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 February 2023 09:20:09 UTC