[webrtc-encoded-transform] generateKeyFrame algorithm makes wrong assumptions about number of encoders (#145)

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

== generateKeyFrame algorithm makes wrong assumptions about number of encoders ==
https://w3c.github.io/webrtc-encoded-transform/#KeyFrame-algorithms

> 1. Gather a list of video encoders, named videoEncoders from encoder, ordered according negotiated RIDs if any.

VP8 in libvpx based encoders use a single encoder to encode multiple spatial layers.
In libwebrtc H264 simulcast is done by a triplet of separate encoders but there seem to be encoders such as OpenH264 with built-in support for multiple spatial layers.

> 4. [...] videoEncoders is expected to be empty if the corresponding [RTCRtpSender](https://www.w3.org/TR/webrtc/#dom-rtcrtpsender) is not active

I don't think that is how things behave.

> 6 [...] If rid is undefined, set rid to the RID value corresponding to videoEncoder.

The video encoder might not have a rid in non-simulcast cases.


Overall the algorithm seems overly specific and should not attempt to venture into such details.
Something along the lines of "ask the encoder to generate a keyframe for the given set of rids or all available layers if the set is empty"

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


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

Received on Tuesday, 30 August 2022 09:00:17 UTC