jlaine

So far the main CPU hog is (unsurprisingly) media encoding, especially video. Luckily this occurs off the main thread, inside C function calls. Unless I'm mistaken the GIL is released, so there is no Python-specific downside on this specific point.

I've found heavy usage of asyncio.Queue to bridge consumers / producers does not lead to amazing performance, so I'm trying to cut down on that pattern in favour of.. callbacks (I know - not very asyncio-ish). A good testcase for testing performance without media encoding is transferring large amounts of data over datachannels (see datachannel-filexfer example). I usually hit ~ 70Mbps on the loopback interface, which is more than I've managed to get out of browsers.

I can't say I have experience with using aiortc at scale yet, so there are almost certainly so hotspots I haven't seen.

There are several examples available from the project's github repo:

https://github.com/jlaine/aiortc/tree/master/examples

I personally like the "server" and "apprtc" demos as you can easily talk to a browser. They illustrate slightly different things:

- "apprtc" relies on a third-party signaling service, and shows you how you can play media from a file / record it to a file, or generate video frame-by-frame.

- "server" shows you how you can combine media and signaling into a single Python-based server, and how you can apply image processing on the fly to the received video.

I can confirm you can get data channels to work with zero SCTP extensions, I only added them afterwards!

One implementation (libusrsctp-based) you might want to interop with is rawrtc. Like aiortc's datachannel-cli example, it features copy-and-paste signaling which makes testing easy.

https://github.com/rawrtc/rawrtc

Lennart, rawrtc's author is very knowledgeable in all things DataChannels and active in the standardization process.

That's good news, the WebRTC world is too much of a libusrsctp monoculture to my taste at the moment. Don't be surprised if you find some interesting edge cases in browsers as you stray from the beaten track :)

https://bugzilla.mozilla.org/show_bug.cgi?id=1443032

Duly noted, I've opened an issue to track this:

https://github.com/jlaine/aiortc/issues/76

aiortc's RTCPeerConnection indeed uses RTCRtpSender.send to apply parameters. This is directly inspired by ORTC:

http://draft.ortc.org/#dom-rtcrtpsender-send

Is there any specific area you spotted which would need some love? Modern spec compliance is most definitely a goal (e.g. RTCRtpTransceiver has been there from the start, aiortc uses the "modern" SDP form for data-channels), so any pointers are greatly appreciated!

I've had some great interactions with the Mozilla crowd (hey Lennart, hey Nils) - looking forward to more of the same!

Signaling is a very app-specific question, as you can use a wide range of options. If you take a look at the "apprtc" example, it's a demo which uses appr.tc's signaling.

You can indeed use aiortc facing a browser, itself or any valid WebRTC endpoint.

Sure, you can use aiortc for a desktop application. However for this specific usecase embedding a browser which supports WebRTC (say QtWebEngine) might be a good option too.

ORTC is what Microsoft has chosen to implement in Edge, so if you use WebRTC in Edge, you're most likely using the WebRTC-over-ORTC adaptor.

In short ORTC is: break WebRTC into objects you manipulate directly, instead of everything being instanciated via RTCPeerConnection. There is significant overlap between the two specs, for instance RTCRtpReceiver / RTCRtpSender.

Absolutely, might as well enjoy the rich Python ecosystem!

Starting with aiortc 0.9.9, there is now also deep integration with PyAV for all your FFmpeg needs.

- At the lowest level : aiortc uses PyAV's AudioFrame and VideoFrame class, and PyAV is soon to gain more ndarray converters: https://github.com/mikeboers/PyAV/pull/415

- At a higher level : aiortc provides MediaPlayer and MediaRecorder classes to read or write audio/video

Actually that would be SCTP over DTLS over UDP (see RTCDtlsTransport class), and a QUIC transport might be an option in the future:

https://groups.google.com/a/chromium.org/forum/#!topic/blink...