-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sections 3.10.1, 3.10.2 and 3.10.3: Control of packetization/depacketization #96
Comments
I see these questions as relating to the question of whether we support custom packetizations or not. 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. |
This issue was mentioned in WEBRTCWG-2023-05-16 (Page 15) |
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?
The text was updated successfully, but these errors were encountered: