- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Oct 2023 12:17:24 +0000
- To: public-webrtc-logs@w3.org
to @Philipel-WebRTC - I don't understand your proposal. In particular: - h.264 has two packetizers, distinguished by "packetization-mode=0/1" in the fmtp string. This is part of my argument for using a full codec description to identify the packetizer. - codec names have to be unique, and if standardized names are used, they need to be used for standardized codecs - there's no particular reason why the SDP exchange should have to reveal to a signaling eavesdropper what the inner content of a nonstandard encrypting codec is There is no standard at the moment for a raw packetization format. So we can't refer to that format from a standard. A goal of standardization is interoperability - that a depacketizer in one browser should be able to depacketize content that is packetized by another browser. So referring to an unspecified format is not a win here. I thought about using a DOMString for "setPacketizer" rather than a codec description, and allowing implementations to put non-specified values in there. But I didn't find any particular advantage in doing so. -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/pull/186#issuecomment-1755264209 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 10 October 2023 12:17:25 UTC