Sections 3.10.1, 3.10.2 and 3.10.3: Control of packetization/depacketization

[aboba]

In the use case described in Section 3.10.1, I wonder what happens if the traffic cam supports a codec (e.g. AAC or H.264/SVC) that is not supported in WebRTC. Can the application still receive the encoded frames and send out RTP packets?

In the use case described in Section 3.10.2, what if the stored content uses a codec not supported in WebRTC-PC? Can the application de-containerized the encoded frames and send out RTP packets?

In the use case described in Section 3.10.3, can the application handle de-packetizing and then pass the frames to WebCodecs or a WASM decoder for decoding?

Is there a requirement for the application to be able to control packetization/de-packetization?

[alvestrand]

I see these questions as relating to the question of whether we support custom packetizations or not.
Custom packetizations would go together with custom codecs - I wrote these use cases without mentioning custom codecs, because I think they are valid use cases when using supported codecs (and HEVC packetization is supported by current WebRTC implementations - used with hardware HEVC implementations).

So I think we need to add an use case for using a custom codec ("3.10.xx Like 3.10.1, but the external device uses a codec that is not supported in webrtc") to make the case for packetization control.

[dontcallmedom-bot]

This issue was mentioned in WEBRTCWG-2023-05-16 (Page 15)