chadnickbok
Joined 15 years ago
Joined 15 years ago
We can support almost any valid h264 file :D
In an ideal world, you'd send 1080p high profile h264 encoded with a bitrate above 8Mbps (or CRF 18 for x264 nerds), with a max keyframe interval of around 5 seconds. Closed GOPs also makes processing more efficient.
In addition, the SDP exchange also sets up DTLS, making sure that whoever the WebRTC SDP was exchanged with is the same as whoever connects at a low-level. While you can implement this as a messaging exchange over UDP once the connection is established, its a nice property that WebRTC doesn't even allow the connection to be established with a non-secured link.
I think the hardest part of the stack is getting a decent, stand-alone implementation. With things like Websockets creating a server is straightforward, but libraries for low-level webrtc are much harder to build.
The ICE RFC does a good job of explaining it: https://tools.ietf.org/html/rfc5245#section-2.7
Once you realize its just ICE + DTLS + SCTP, and that each layer has a corresponding library, the work getting it up and running is mainly just 'plumbing'.
Here's a link to the library I've been working on: https://github.com/chadnickbok/librtcdcpp
Its still new, but we're starting to pick up some steam in the pace of development, and we have a pretty easy demo in the repo.
Thanks! Keep up the great work ;)
If you're interested in this sorta thing, try taking a look at Broadway JS: https://github.com/mbebenita/Broadway
Here's a simple demo page they have setup: http://mbebenita.github.io/Broadway/foxDemo.html
Its entirely possible to use WebSockets to stream H264 to a browser and decode using broadway, and the performance is pretty good, even on mobile.
Also on desktop this link points to latest: https://twitter.com/search?f=tweets&vertical=default&q=route...