What is the right behavior of sendKeyFrameRequest in some corner cases? #280
Description
The WPT currently says:
Reject for unused transforms
Do not reject for unset transforms
Do not reject for stopped receivers
The implementations run the test as follows:
Safari (latest Tech Preview I could get as of today):
- Rejects for unused transforms (passes the WPT)
- Leaves the promise hanging for unset transforms (passes the WPT)
- Leaves the promise hanging for stopped receivers (passes the WPT)
Firefox (latest nightly I could try as of today)
- Rejects for unused transforms (passes the WPT)
- Rejects for unset transforms (fails the WPT)
- Resolves for stopped receivers (passes the WPT)
Chrome (latest Canary I could get as of today with experimental features enabled)
- Rejects for unused transforms (passes the WPT)
- Rejects for unset transforms (fails the WPT)
- Rejects for stopped receivers (fails the WPT)
The send request key frame algorithm says:
Reject if depacketizer is not defined
Reject if depacketizer does not belong to a video RTCRtpReceiver
Otherwise resolve (the actual request is not necessarily sent in this case).
It does not seem to me that leaving the promise hanging is a valid outcome of the algorithm.
Everyone agrees that unused transforms should reject as it corresponds to the case where the depacketizer is undefined.
While the spec doesn't have text to update the depacketizer when the transform is unset, it seems to me that the intent is that it can be considered undefined and should reject as well.
For a stopped receiver I think the depacketizer is defined and, assuming it is video receiver, it seems to me that the promise should resolve.
In short, I think Firefox's behavior best matches my interpretation of the spec (my current plan is to change Chrome to match Firefox here).