W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > October 2022

Re: [webrtc-encoded-transform] Add use cases that require one-ended encoded streams (#106)

From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
Date: Tue, 25 Oct 2022 10:09:58 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1290307188-1666692596-sysbot+gh@w3.org>
the motivation for #154 was such a one-ended use-case.
We use encoded transform to do process  encoded data sent over a PeerConnection (second bullet above) and receive a custom codec over RTP[^1].
For that use-case it is useful to know the  RTP timestamp to allow the "jitter buffer" to detect losses [^2]. The data received gets decoded using WASM (or Webcodecs) and does not get enqueued back into the normal webrtc pipeline (or a silent frame gets enqueued instead while playout is handled differently)

[^1]: note that this would benefit from [BYOC](https://github.com/w3c/webrtc-encoded-transform/issues/121#issuecomment-934674380) and better integration into SDP. Currently it needs to pick a negotiated but effectively unused payload type from the SDP (such as G711a)
[^2]: it might also be useful to have the [receiveTime](https://wicg.github.io/video-rvfc/#dom-videoframecallbackmetadata-receivetime) from rVFC

GitHub Notification of comment by fippo
Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/issues/106#issuecomment-1290307188 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 25 October 2022 10:10:00 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:59 UTC