On 11/09/2020 12:31, Sergio Garcia Murillo wrote: > Hi all! > > WebRTC can be an intimidating monster, and we all are aware of that. > Also, the fact that every webrtc media server/service has their own > custom protocol has not helped to increase its adoption in the streaming > world, with still relies heavily on other protocols like RTMP, SRTP or > even RTSP for ingesting content. > > In order to try to broaden the adoption of WebRTC in the streaming > world, and make it available in OSS tools like ffmpeg, gstreamer and > OBS, we have created the Webrtc Http ingest protocol (WHIP), so the same > implementation works across several (hopefully most) webrtc services and > media servers. > > The first draft is available here: > > https://tools.ietf.org/html/draft-murillo-whip-00 > > The latest editorial draft is in this gitup repo: > > https://github.com/murillo128/webrtc-http-ingest-protocol > > The feedback from the webrtc community has been very positive so far, as > this has been a recurring burden for years, so the adoption on that side > is very likely to happen. I have already implemented it on my media > server (https://github.com/medooze/media-server-node) and we will > disclose more information about how to test and interoperate with our > implementation during next week. > > Myself and other webrtc devs are willing to collaborate in the > implementing this into ffmpeg, as it would be huge for the webrtc comunity > > I would love to hear the feedback from you, the ffmpeg devs, to the > draft so we can improve it and make it easier to implement it in ffmpeg. > What do you think? > > Best regards > > Sergio > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Honestly, this is pretty meh. While it makes the job of the ingest server easier, what I and most of us in the community would have really liked to see is something like Matroska sent over a UDP protocol with adjustable error correction settings, error detection and built-in redundancy. Basically, SRT but with Matroska instead of mpegts, or at least a variant of ISOBMFF. And rather than it being published a WebRTC-specific protocol, a general protocol implementing support for multitude of codecs. Matroska is already close to being an IETF standard (draft-ietf-cellar-matroska-05) itself, so you wouldn't even have had to specify the container, and for the protocol itself, even the most basic of error correction Hamming codes would suffice, and such could be even worked into Matroska itself so only the data which matters would be protected. The only reason why RTMP is still in use and is still worked on (a team not too long ago wrote HEVC encapsulation spec/draft for it) is because despite of its shortcomings, its ubiquitous, generalized, simple and fully encapsulates all data streams sent through the FLV container. FFmpeg's RTP support is honestly pretty broken, and the fact you need separate RTP streams for audio and video pretty much guarantees the streams will be out of sync with the way the current muxers are implemented. So even if this protocol were to be implemented, it wouldn't work any better than just sending 2 RTP streams. It is disappointing seeing another standard being written which completely misses the point of what an ingest protocol (or simply even an end-to-end protocol) would look like. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
