-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Projects Worth Doing
This is a list of projects that pass these tests.
- Improvements for users is clear
- Can be completed by a single developer
- No bikeshedding. Pion maintainers agree issue is worth solving.
- Fun/rewarding for developer. It's a project someone can be proud of
Pion sends UDP packets one at a time. Doing this send syscall is the most expensive operation happening for most Pion users. For some platforms it is possible to batch the sending of packets. We can send multiple UDP packets at one time!
This can be implemented in a few different ways, but this would be a good way to start.
- Write a simple server that sends 4K video or maybe lots of data via DataChannel?
- Modify pion/ice to batch and send packets every ~20ms?
- See if that improves performance!
It's possible that sending on a timer doesn't actually help. We might have to introduce
an API that allows pion/sctp pion/rtp etc... to send multiple patckets in one call.
It would be better if we could do this with no API breakage though! It's possible Go already has a idiomatic solution to this .
SCTP uses a single sequence number when sending data. This means SCTP suffers from Head-of-line blocking. If you are trying to do high performance datachannels you are going to block on old packets that you actually don't care about!
SCTP has solved this with rfc8260. Implementing this in Pion would give a performance benefit to all DataChannel users.
Currently pion/sctp uses packet loss as the only input to perform Congestion
Control. If we used packet arrival times we would get more robust/faster
DataChannels!
Rack for SCTP is the best thing to read on the topic. It ends with a very exciting summary.
The RACK algorithm shows a significant
improvement over the dupthresh algorithm, especially for non-
saturated connections and in the event of tail loss. The benefits
are not limited to loss. RACK is also much more resilient
against packet reordering in the network.
Pion currently only supports DTLS 1.2 implementing 1.3 has a bunch of improvements that would help out Pion users.
- Faster connect times (One less round trip during handshake)
- Less overhead (Record layer is smaller)
- Privacy (SeqNums encrypted )
- Security (Only AEAD ciphers)
WebRTC connection times are slower if Pion is the Controlling ICE Agent (vs the Controlled Agent). This has been filed as the following issues.
If these are fixed we could reduce the connection times by 2 seconds in some cases!
Having this in-tree would make building media projects a lot easier! Connecting WebRTC to SRT and other systems often involves having to process MPEG Transport Streams.
See pion/webrtc#3169
WebRTC developers are often frustrated/confused by the Offer/Answer in WebRTC. This project offers a Web UI where developers can paste in their offer/answer and then lets them interact and modify to learn more.
It might make more sense to restart this project from scratch! The project involves
using Go + WASM and pion/sdp to parse and explain the values.
You can then link to webrtforthecurious.com maybe to help teach users.
Pion Opus only provides a Silk Decoder. This will be a long project, but maybe starting with a Silk encoder is a good place.
When this is complete we could provide users with pure Go conferencing software!
Lots of great Pion projects have been built recently. We should update https://github.com/pion/awesome-pion to show them off
We should look through all the v3 importers on this page and update them to v4 if possible.
If they can't be updated to v4 we should fix the problem that is keeping them on v3!
Sign up for the Pion Discord for discussions and support
If you need commercial support/don't want to use public methods you can contact us at [email protected]