Can I access to raw RTP stream from a web browser?

[Akon2]

I'm having H264 real-time video stream issuing by gst-rtp-server. Moreover, there is possibility to use an augmented FEC stream from the server to improve performance in noisy environment (like WiFi). FEC works on RTP layer. So, on a client side these two RTP streams must be combined into a final one.

Using GStreamer on a client side inside a dedicated native app works perfectly. But, instead of such native app I'm also considering a modern HTML5 Web browser to receive and render the video stream.

So, formal question: Is it possible to get raw RTP video stream from a modern browser somehow? I need to support iOS, Android, as well as main desktop systems.

Currently, I'm considering GSreamer-based preprocessing on a client side - standalone tiny GStreamer-based service (native GUI-less app) will be activated from a webpage and will perform RTP and FEC-based processing, depaying from RTP and paying to something that HTML5 supports. That new stream then will be issued from the localhost to HTML5's 'video' tag on the webpage.

Alternatively, such GStreamer-based service may be implemented as a NPAPI plugin, but nowdays NPAPI is deprecated way and might be not supported at all.

Any other ideas?

Thanks.

[Baby Octopus]

WebRTC, no?

[Akon2]

WebRTC: does it give access to RTP layer? If so, what's API: C++, javascript, etc?

[Arjen Veenhuizen]

It sounds to me that you try to re-invent the wheel a bit here. WebRTC has all you need (play live low latency audio/video in a browser, out of the box FEC support, STUN/TURN for NAT traversal, etc.). If you need integration with GStreamer, checkout Kurento; the Janus Gateway is an excellent alternative.

[Akon2]

Thanks for the info. That things look promizing! The project was originated from the point were a server was gst-rtsp-server, a client was a native app, H.264 hardware encoding/decoding was a requirement, so GStreamer was a good choice.

How does WebRTC integrate with modern browsers? Nowadays NPAPI plugins are not recommended and might disappear in near time at all (except Flash, maybe). I'm thinking WebRTC code is a part of a browser code, so a proper testing by the browser developer, for instance, for security issues might be expected. Am I right?

[Arjen Veenhuizen]

WebRTC support is pretty good nowadays. Chrome and Firefox have native support out of the box, Safari will be supported when the new macOS High Sierra is released and Edge is quickly catching up as well. No more hassle with ancient NPAPI or, dare I say, Flash.

[Nicolas Dufresne-5]

Le mercredi 26 juillet 2017 à 23:37 -0700, Akon2 a écrit :
> How does WebRTC integrate with modern browsers? Nowadays NPAPI plugins are
> not recommended and might disappear in near time at all (except Flash,
> maybe). I'm thinking WebRTC code is a part of a browser code, so a proper
> testing by the browser developer, for instance, for security issues might be
> expected. Am I right?

WebRTC is part of the browser yes. WebRTC itslef is the API expose in
JavaScript and it's integration with video/audio tags. Under hood, it's
implemented following various RTP standards, it's always encrypted
using DTLS. Most browser base their implementation on the same C++
library, libwebrtc [0]. GStreamer integration has been made, see
OpenWebRTC, Kurento and Janus. Though, it's not supported out-of-the-
box by upstream GStreamer.

regards,
Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le jeudi 27 juillet 2017 à 09:59 -0400, Nicolas Dufresne a écrit :

> Le mercredi 26 juillet 2017 à 23:37 -0700, Akon2 a écrit :
> > How does WebRTC integrate with modern browsers? Nowadays NPAPI
> > plugins are
> > not recommended and might disappear in near time at all (except
> > Flash,
> > maybe). I'm thinking WebRTC code is a part of a browser code, so a
> > proper
> > testing by the browser developer, for instance, for security issues
> > might be
> > expected. Am I right?
>
> WebRTC is part of the browser yes. WebRTC itslef is the API expose in
> JavaScript and it's integration with video/audio tags. Under hood,
> it's
> implemented following various RTP standards, it's always encrypted
> using DTLS. Most browser base their implementation on the same C++
> library, libwebrtc [0]. GStreamer integration has been made, see
> OpenWebRTC, Kurento and Janus. Though, it's not supported out-of-the-
> box by upstream GStreamer.

I forgot to mention, WebRTC usually enables retransmission and adaptive
rate control rather then FEC. This is of course best suited for end-to-
end communication (lower server overhead per channel). FEC is best
suited for broadcasting, when the server produce one stream and client
need to dead with it. Though, the spec is not restricted, if your FEC
implementation is based on an standard, then you should have all the
needed bits to negotiate it through the SDP (WebRTC, just like RTSP,
uses SDP exchange to negotiate the RTP features).

>
> regards,
> Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Akon2]

Ok, taken into account. Thanks!

I refine, that in the project there are broadcast and real-time streaming.