- From: Philipp Hancke via GitHub <noreply@w3.org>
- Date: Thu, 31 Jul 2025 16:35:28 +0000
- To: public-webrtc-logs@w3.org
> I've found no sign of more than 3 proposals in the [slide deck](https://docs.google.com/presentation/d/1HUx-gh2RlNMCjHNbTjQYvrPcLmov8Sq8MAC7sNxXbB8/edit?slide=id.g1502ae48044_0_63#slide=id.g1502ae48044_0_63). Slide 114 in the overflow section, see also my email linked from the very comment you quoted @jan-ivar. > The current API (before and after the proposed change) is allowing this. @youennf as you point out as the single-rid variant opts in for having to ensure it behaves "nicely" (i.e. not with two key frames ideally) to separate calls which effectively requires aggregating two subsequent calls into a single call to the encoder (as in the case of simulcast it is hard to know whether the encoder is capable of simulcast or not). This is an overly complex design. See @solmaks' https://github.com/w3c/webrtc-encoded-transform/issues/143#issuecomment-1262108363 for the use-case which from what I recall is solved by https://wpt.fyi/results/webrtc/RTCRtpSender-setParameters-keyFrame.html?label=experimental&label=master&aligned I thought we had agreement that the RTP timestamp is useless, in particular if it is not shared among different simulcast streams? -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/143#issuecomment-3140615545 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 31 July 2025 16:35:29 UTC