Add a metadata modifying method to RTCEncodedFrame

[alvestrand]

In support of solving #160, allow the modification of metadata on an RTCEncodedFrame.
The following items have been identified as targets for modification:

• PT number
• SSRC
• CSRC

These are items that may be negotiated differently for different transports, and should therefore be modifiable.

Use case: https://w3c.github.io/webrtc-nv-use-cases/#auction

[henbos]

The RTCEncodedVideoFrameMetadata appears to be a mix of encoded chunk metadata (which should be settable for "bring your own encoder" use cases) and RTP related metadata (PT/SSRC/CSRC).

Being able to set the RTP related fields would certainly be a good start!

[Orphis]

SSRC should maybe not be exposed, but the rid could be updated (and validated on the matching sender).

[henbos]

There's currently no way to tell the encoder which RTP stream / encoding layer to forward the encoded chunk to other than by SSRC. But if instead of specifying SSRC you specified encoding layer, that would remove the need to figure out what SSRC to use.

It's a good point actually. When we hacked together a POC, we obtained the SSRC by parsing SDP. But that SSRC is only exposed for backwards compat reasons, it would be perfectly valid for the browser not to expose what the SSRC is, so what would you do then? Using the encoding layer's index sounds more future-proof and makes the API simpler to use since you could use the same identifier regardless of which RTCRtpSender happens to be the receiver of the chunk!

[henbos]

Or RID like you say rather than index

[fippo]

see #147 for adding MID and RID. So far amazing stuff has been built without them.

[jan-ivar]

If we can change the data and the metadata, what's left?

With this and #160 is a constructor that lets you specify metadata maybe what we want instead?

[dontcallmedom-bot]

This issue was discussed in WebRTC July 2023 meeting – (SetMetadata for redundant relay PCs.)

[alvestrand]

The resolution in July was "Discussion should continue on Github".
Seems quiet - can we just move ahead with a PR so as to make the discussion concrete?

[palak8669]

PR: #202

[dontcallmedom-bot]

This issue was mentioned in WEBRTCWG-2023-09-12 (Page 50)