On 11/09/2020 13:49, Lynne wrote:
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.
Thank you for your honest feedback.
I might have added a bit of context about what is its intended usage to
set expectations correctly.
The idea behind whip is not about proposing a general ingestion content
to replace SRT/RTMP, but to allow ingesting webrtc ultra low delay media
into a webrtc server to avoid having to do protocol/codec conversions on
the server and preserve the webrtc properties end to end (bandwidth
estimation, congestion control, nack, rtx, fec, simulcast and svc
support, nat traversal and end to end encryption with an end to end
delay of less that 100<ms)
In that context a matroska over udp would be as useless for the webrtc
community as current RTMP/SRT.th
While I acknoledge that this might be useless for vod-like ingestion,
there are already a lot of interesting webrtc services that could
benefit from this (and from the feedback I have got, it is a real need).
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.
I have suffered ffmpg rtp support for years, that's why we volunteer to
help with that part of the development.
WebRTC uses rtp muxing to send all data in the same udp port, and lip
sync based on rtcp (also muxed on same udp port). It has been working
for years.
It has also bandwidth estimation, congestion control, nack, rtx, fec,
simulcast and svc support, nat traversal and end to end encryption with
an end to end delay of less that 100<ms.
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".
