It's certainly not better than FFmpeg. But I had a look through the source code and the author seems to have a fairly good grasp of WebRTC. The library looks really useful for anyone that wants to quickly understand WebRTC and how to use librtp and libsrtp. It's mostly a bare-bone wrapper around those libs.
Yep, it looks easy to replace the function h264_get_next_frame(). I think you could get really decent performance if you used ffmpeg to pre-extract all of the frames into sequential files and serve them statically.
Just for completeness sake this is what docs [1] state:
"For most WebRTC applications to function a server is required for relaying the traffic between peers, since a direct socket is often not possible between the clients (unless they reside on the same local network). <...>"
STUN is just for punching holes in your NAT router, and also discovering what is your public IP address. Both things will be needed for the other peer to know where to reach you. And the other way around.
Once this NAT thing has been done by both parts, and the actual communication has started directly P2P, STUN is not needed any more.
That is partially incorrect, STUN can punch a hole through even when both sides uses NAT in many cases. That is what I would classify as STUN’s main feature.
Note that parent said “ if both peers are behind NAT without UPnP”. As far as I know, there’s no way to punch holes / open ports automatically without UPnP.
If we are still in the 90's that definition of "true p2p" would be: two computers with both having public IPs and transferring packets via TCP. But nowadays we are always behind NATs so we became less strict with the definition of what is true p2p
IPv6 is slowly taking over, hopefully in the near future being behind a NAT will be considered abnormal (just like happened with Unicode, we're around 35% = "Unicode 2009", popularity-wise).
Your p2p nodes might not be behind NAT. In a lot of populations you can rely on everyone having working v6 for example.
I think the question of what's "pure" p2p is somewhat academic. If your app uses DNS, is it p2p, isn't DNS just a distributed p2p database? Does p2p require that every aspect of your app right down to discovery is distributed among nodes running your app? Is it cheating to use an existing DHT? etc.
Careful! P2P streaming video is a (completely non obvious, according to the courts) infringement of the VirNetX patent that for example
Apple just had to pay a few billions of dollars for.
If you implement p2p video streaming chances are no company will want to touch it with a ten foot pole.