Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add use cases that require one-ended encoded streams #106

Open
alvestrand opened this issue Apr 29, 2021 · 5 comments
Open

Add use cases that require one-ended encoded streams #106

alvestrand opened this issue Apr 29, 2021 · 5 comments
Labels
editorial

Comments

@alvestrand
Copy link
Contributor

Use cases that are obvious:

  • WebRTC codec, encoded data carried over another transport (such as Datachannel or WebTransport)
  • WebCodec codec, encoded data sent over a PeerConnection
  • Encoded data feeding into a timing adjuster (NetEq) that uses WebCodec to decode and play out time-adjusted data

These need to be written up somewhere.
@fippo
Copy link
Collaborator

fippo commented Sep 2, 2022

@alvestrand has this been overtaken by your new proposal?

@alvestrand
Copy link
Contributor Author

I think this is the previous iteration of the line of thought that led to my present problem description, yes. So it may make sense to point this bug at that proposal.

@alvestrand
Copy link
Contributor Author

Link to the writeup: https://lists.w3.org/Archives/Public/public-webrtc/2022Aug/0032.html

@alvestrand alvestrand mentioned this issue Sep 9, 2022
Open
@fippo
Copy link
Collaborator

fippo commented Oct 25, 2022

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 RTP1.
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)

Footnotes

  1. note that this would benefit from BYOC 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 from rVFC ↩

@alvestrand
Copy link
Contributor Author

One use case bug raised (no PR yet): w3c/webrtc-nv-use-cases#77

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
editorial
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dontcallmedom @fippo @alvestrand