WebRTC surveillance use case

[hamphiterus]

Hello all, 

Thank for your attention, 

It's possible to connect one IP camera (rtsp) -> to WebRTC directly ?

In case not, what's is the better solution to connect IP Camera to page HTML5 ?  

[hu]

there are a very good post. you can refer it.

http://www.codeproject.com/Articles/800910/Broadcasting-of-a-Video-Stream-from-an-IP-camera-U

[Luis Lopez]

The best approach for doing what you want is through a WebRTC media server with transcoding capability. For example, using Kurento Media Server you can just instantiate a PlayerEndpoint (which is capable of receiving RTSP streams from the IP camera) and connect it to as many WebRtcEndpoints as you want to distribute the media to WebRTC capable clients.

The pipeline is the following.

IP Camera -------(RSTP/RTP stream)----------> KMS PlayerEndpoint -----(N)------> WebRtcEndpoint ---------(WebRTC stream)-------> WebRTC Clients.

Best.

Luis Lopez
Kurento.org Project Coordinator
+34 914 888 713 • lu...@kurento.com • prof.luis.lopez • • • •

---

Best WoW Factor Award at WebRTC Conference & Expo 2014 (California)

Audience Choice Award at WebRTC Conference & Expo 2014 (California)

Best of Show Award at WebRTC conference expo 2014 (Paris)

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hamphiterus]

Yes kurento is one solution for this case, but i think this is not a better solution. Because the delay between send media stream and receive media stream is some.

I am wrong ?

Thank's for your help.

Best regards.

[Luis Lopez]

Hi,

The point is that you need to perform a transcoding somewhere. At the camera you can't (at least in most cameras I know about) and at the browser you can't either. Hence, your only chance is to put something in the middle: call it media server or whatever.

In the particular case of Kurento, the latency increase due to transcoding is under 200ms. Depending in your use case this may be relevant, but for most video surveillance scenarios that latency increase is not relevant.

Best.

Luis Lopez
Kurento.org Project Coordinator
+34 914 888 713 • lu...@kurento.com • prof.luis.lopez • • • •

---

Best WoW Factor Award at WebRTC Conference & Expo 2014 (California)

Audience Choice Award at WebRTC Conference & Expo 2014 (California)

Best of Show Award at WebRTC conference expo 2014 (Paris)

[hamphiterus]

One more question. I can connect the IP Cam (rtsp://192.168.0.99:554/axis-media/media.amp) without trans-coding to Kurento ? Or before send the stream to kurento is necessary to convert Stream to RTP stream ? 

[Luis Lopez]

RTSP is a signaling protocol, RTSP will not be the transport protocol of the media. The IP Cam will send the media using RTP/H.264. For receiving that media into Kurento you don't need any kind of transcoding. The transcoding only happens if you want to send that media to WebRTC browsers. In that case, one H.264 to VP8 transcoding will take place (only one independently on the number of WebRTC receivers you hook)

Luis Lopez
Kurento.org Project Coordinator
+34 914 888 713 • lu...@kurento.com • prof.luis.lopez • • • •

---

Best WoW Factor Award at WebRTC Conference & Expo 2014 (California)

Audience Choice Award at WebRTC Conference & Expo 2014 (California)

Best of Show Award at WebRTC conference expo 2014 (Paris)

[Jeremy Noring]

Guy who spent about a decade in video surveillance here.

Possible, but hard to do the *right* way (for the wrong way, see below).  Also problematic to do until Chrome gets H.264 decode support (or you find embedded VP8/9 encoding solution...which is hard and/or $$$).  You'll need a version of webrtc compiled for your embedded environment that could somehow digest your H.264/VP8/opus encoded media (probably a royal pain in the butt).  You don't need an MCU (you will need a signaling server--websockets is probably ideal--and STUN/TURN server for NAT traversal).  And of course, you'd want a layer of security on top of all this so the camera didn't establish connections with unauthenticated peers, but that's outside of webrtc.  This would also make two-way communication (e.g. push to talk, which is an oft-requested feature in video surveillance) a lot easier.

The wrong way: relay through an MCU.  This is easier in some regards (you can transcode at the MCU, or re-packetize to completely different formats, like RTSP/RTMP/etc.--it's certainly a more flexible solution), but there's a huge scale cost, lots of additional latency, deploy headaches (do you put servers just in the US?  Around the world?  How do you pin cameras to servers?  Yuck!), a ton of additional complication, etc.  It's also generally less secure, because formats like RTSP/RTMP/etc. generally have scant encryption (if any at all).  One of the great things about WebRTC is security is a first-class citizen, and guess what?  People are kinda paranoid about video streams coming out of their house.

Having thought about webrtc and video surveillance....it's actually kind of a "duh" combination, and I'm surprised there's so little interest in the surveillance market.  You get nice, low-latency video and peer-to-peer connectivity which dramatically reduces the complexity of your overall system. No wowza headaches. Signaling can easily be combined with whatever signaling protocol currently being used.  A clear path to migrate away from Flash-based solutions.  iOS and Android support (a little rough around the edges, but it's getting there).  I'm surprised there aren't more security vendors working on this (uh, dropcam...you're technically part of google?).

 

[hamphiterus]

Hello Jeremy, no i'm not a techincally of Google, I'm a developer and i need to develop one system surveillance, when i capture N media Streams for N IP Camera and display in one page HTML5. 

Kurento use Gstreamer multimedia framework for trans code stream to HTML5 stream. I think this part can be made on my application. In which case the transmission speed is greatly improved.

Your opinion is welcome.

Best Regards.

[Jeremy Noring]

On Friday, January 30, 2015 at 3:46:46 AM UTC-7, hamphiterus wrote:

Hello Jeremy, no i'm not a techincally of Google, I'm a developer and i need to develop one system surveillance, when i capture N media Streams for N IP Camera and display in one page HTML5. 

Kurento use Gstreamer multimedia framework for trans code stream to HTML5 stream. I think this part can be made on my application. In which case the transmission speed is greatly improved. 

Your opinion is welcome.

And I gave it.  I wouldn't build it like this, and I think the requirements are completely wrong, but if that's what you need, kurento's probably your least painful route.

[Hasmukh Ginoya]

Hi,

I have started feasibility on webRTC Stack. So can we use WebRTC for our video surveillance application in which N number of IP Cameras are connected with one streaming Server and on the top of the webRTC Server will be there , When any web browser client request for live stream then webrtc server and streaming server will stream compatible browser to display.

So this can be done with WebRTC ?

Can we use this purpose  ?

I am really confused on this matter ?

[Jeremy Noring]

Yes, you can use it, but it won't be simple.  It'd require porting webrtc to run in an embedded environment, and integrating hardware encoders (preferably VP8/Opus) into that ported version of WebRTC.  An embedded device running android would probably be easiest, but that comes with a whole host of issues as well.

The big advantage of WebRTC is you *would not* need any sort of media server.  You'd need a signaling server of some sort for general communication, and then a TURN server at most to handle cameras that couldn't establish a peer to peer connection, but beyond that, most connections would likely be established via p2p.

I'm still surprised the surveillance industry hasn't picked up on using WebRTC.  It would solve about half a dozen of their biggest problems on day 1.

[Lorenzo Miniero]

Apologies for the self plug, but just FYI, some companies have started using Janus for the purpose. We also do support the restreaming of an RTSP url, but it doesn't transcode so that only works if the codecs are supported by the browser (otherwise, as Luis said, you need transcoding somewhere).

L.

[Ivan Gracia]

Now that FF and Chrome support H264, you could have your WebRTC endpoints in Kurento Media Server use that, so you don't need to do any transcodification from your RTP/H.264 feed. Apologies also for the self plug, too!

[Jeremy Noring]

Even better, you could skip the MCU entirely and stream directly from camera to browser.  The MCU is only important if someone wants to do a one-to-many (or many-to-many) scenario.

Also, H.264 support in the embedded space is dramatically more mature than VP8/9, so that'd alleviate that issue as well.

[James Kaye]

I'd imagine the reason companies arent directly streaming from camera to browser is for authentication purposes.... would there be a way to authenticate a browser's inputted login credentials with some database in order for a direct stream from camera to browser to be formed? Also how difficult would it be to stream webRTC from a simple linux-based ip camera?

[Kaiduan Xie]

"Also how difficult would it be to stream webRTC from a simple linux-based ip camera?"

What is the typical Linux based IP camera hardware configuration particularly CPU, memory? You need to run the webrtc native stack in the Linux based IP camera, also there may be some modifications required to use the hardware H.264 encoder on Linux IP camera with webrtc native stack.

Best regards,

/Kaiduan

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/cc17f600-c69e-4627-9ebf-482e9b4b39b0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Founder of Goodstartsoft

https://www.goodstartsoft.com

[jons...@gmail.com]

On Sat, Jul 1, 2017 at 10:07 AM, Kaiduan Xie <kaid...@gmail.com> wrote:
> "Also how difficult would it be to stream webRTC from a simple linux-based
> ip camera?"

Build the code here: https://webrtc.org/native-code/development/
That makes executables to do webrtc from the command line under Linux.
It is set up for the desktop where the CPU is powerful enough to do
enc/dec in software.

Now you need to port it to a SOC camera chip. These SOCs normally run
Linux and their SDKs come with an API for accessing the hardware
enc/dec support and the image sensor. This is where everyone gets in
trouble, no one ever finishes this porting step. I don't know of any
reason why it wouldn't work, it just involves some effort getting the
code running.

But now you are in a quandary. How do you record while WebRTC is
active? All of the recording file formats assume a fixed encoding for
the compression. WebRTC can dynamically change the encoding mid-stream
- like by changing the resolution. When WebRTC does this it
reprograms the encoding hardware. So your WebRTC stream is fine, but
you can't generate a MP4 file anymore, so no more recording.

One way to get around this is to use chips that support multi-stream.
Most security camera chips support two streams (generated off from a
single sensor input) and some support three. So instead of
reprogramming the SOC encoder on-demand for WebRTC, instead
dynamically pick blocks from one of the three streams to send. Now you
can leave the SOC encoding hardware making a good archival stream and
also use WebRTC to view it.

So how to get started? Buy an off-the-shelf Onvif camera. Look in the
Onvif output and find one with two or three stream support. For
example Grain GM8138S or better cameras support three streams.
Hisilicon and lower end Grain are two stream. On a PC use libav (ffmeg
library) to open these three RTSP URLs simultaneously and get the
h.264 out of them. Now go modify the WebRTC code to skip between the
three different resolution streams based on what the client requests.
Also note that you can send a RTSP FIR command to force the generation
of a key frame. Do this on the PC since it is much easier to debug
things there. After you get this working, port it into the camera
chip. Now the camera chip will be able to do both -- Onvif for
recording, and WebRTC for live view.

You could also record the WebRTC stream and play it back. But that
stream has embedded the dynamic network conditions into it. For
example if there were bandwidth issues the stream dropped in
resolution. On playback you may be on a different device and have
completely different playback conditions. So you really want to record
the high bandwidth stream and use it for playback.

Please let me know when you get this working.

>> email to discuss-webrt...@googlegroups.com.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/discuss-webrtc/cc17f600-c69e-4627-9ebf-482e9b4b39b0%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Founder of Goodstartsoft
> https://www.goodstartsoft.com
>

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "discuss-webrtc" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to discuss-webrt...@googlegroups.com.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/discuss-webrtc/CACKRbQfKRgUopwsXtBxnh9CX%3Dc2GjzzR7jZ5W3eQ6ef50a8zVQ%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.



--

Jon Smirl
jons...@gmail.com