- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Oct 2023 12:31:39 +0000
- To: public-webrtc-logs@w3.org
> If we have to handle SDP negotiation and RTP packetization for this use case, and we know that we have other use cases we need to handle it for, why not accept the current proposal into the WD? Web applications are not really blocked by SDP negotiation since they can do all sort of adaption at JS level. I would tend to leave this particular API to the end when we have the other pieces ready. The RTP packetization part of the proposal seems more problematic to me. AIUI, the guidelines from the IETF is that every codec has its own packetization, except for a very few packetization formats, the only one in scope for UA for the moment being SFrame. The proposal here seems to open the box to things like: encode as VP8, packetise as H264. This seems to go against the IETF guidelines. I am ok allowing JS to select other packetisers than the default one, for some very specific packetisers, SFrame being the only one really. Hence the idea to expose `rtpPayloadFormat` and to limit this change to those packetisers, at least at first. For the new codec use case, following the IETF guidelines, plugging a JS codec would mean plugging a JS packetiser/depacketiser. But the proposal does not go there so the proposal does not fully address new codec use case. For the video+metadata, if the packetiser can handle it, I see no missing support. If the packetiser cannot handle it due to the added metadata, it means this video+metadata is a new codec, and it would need its own packetiser. > Doing this without SDP handling would make the current situation, where people send content that does not conform to the SDP describing what they claim to be sending, strictly worse Agreed in general. The rough solution I have in mind is to expose a codec object to JS to surface the control API without allowing JS to actually push arbitrary data. I haven't done the full exercise of how this initial API could be easily extended to fully support new codecs. My hope is that this would be one step forward to modelling the new codec JS API. We would still need to handle the packetization and SDP issues of course. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/pull/186#issuecomment-1766323578 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 17 October 2023 12:31:41 UTC