Skip to content

Instantly share code, notes, and snippets.

@Sean-Der
Created May 20, 2023 16:44
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Sean-Der/7a2e2b77abde69dd83b9a3549859d8d1 to your computer and use it in GitHub Desktop.
Save Sean-Der/7a2e2b77abde69dd83b9a3549859d8d1 to your computer and use it in GitHub Desktop.
Get involved with Pion
Pion has lots of opportunities to get involved. We have lots of self contained projects that would be a lot of fun. Even if you don’t finish the project that is fine. The great thing about Open Source is someone can pick up where you left off.
It’s a great way to learn deep WebRTC knowledge. It is also a great pathway into a career in WebRTC. Multiple Pion contributors now work at companies that use the code they wrote.
—————————————
Network Simulator - Pion needs an easy to use network simulator. Something that developers can use in a few minutes and doesn’t require a Docker container or a long setup process. It can run in memory, but also provides virtual interfaces to test non-Go programs.
The simulator will model real world networks. Nog just setting a static packet loss or bandwidth cap. It can dynamically adjust all the attributes of the link.
We could use it to tests Pion’s GCC and NADA implementation end-to-end. It would also aid in our development of FlexFEC and dynamic JitterBuffer.
More importantly it would allow developers to test their applications locally. Too often developers build interesting programs, but are plagued by the networks of their users.
Dynamic JitterBuffer - A JitterBuffer buffers incoming packets and makes sure they are in order. If a packet was lost in transmission it also allows the developer to respond as they wish (NACK, PLI….)
Pion currently only has a static JitterBuffer. You set a static number of packets you want to wait. Pion can then re-order and send NACKs. This doesn’t work well for diverse networks. This could add latency to users with great networks. Inversely users with bad networks might not have enough delay.
We need a JitterBuffer that grows and shrinks the delay. Instead of expecting users to set a static value we give developers the best experience possible with zero configuration.
FlexFEC - Forward Error Correction is one strategy to overcome packet loss. If you know that packets may be dropped you can send redundant media ahead of time. Even though packets are dropped that redundancy fills the gaps so the user never notices.
Pion has no FEC implementation at this time. Adding a FlexFEC interceptor would be a huge improvement for Pion users. In cases where bandwidth is available but loss is being observed it will be a big improvement over retransmissions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment