On 11/09/2020 17:29, Kieran Kunhya wrote:
On Fri, 11 Sep 2020 at 11:31, Sergio Garcia Murillo <
sergio.garcia.muri...@gmail.com> 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.
There are plenty of protocols for content ingest that are widely used
(RTMP, SRT, RIST etc) that are far superior to anything WebRTC can do.
Why are you conflating a delivery protocol (WebRTC) with ingest? When you
have a hammer everything seems to look like a nail.
Because when you have a WebRTC server/service, you need WebRTC ingest.
You may be surprised by the amount of mixed RTC/streaming services that
are being implemented as we speak since COVID.
You may argue that it is a much lower number than traditional
streaming/broadcasting, which I agree, but you should not diminish then
as it is still a huge (and with lots of potential) market.
Again, this is not about comparing protocols, not trying to convince
anyone to use it instead of SRT/RIST, but trying to find a way to solve
a feature highly requested in the WebRTC community. None of the proposed
solutions works for us if we want end to end delivery with WebRTC.
So I will rephrase my question, in terms of adding whip to ffmpeg, given
current state of implementation and architecture of ffmpeg, is there
anything that can be changed in the protocol so it is easier to implement?
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".
