What is the best solution to display multiple live streams from a surveillance camera (so low latency is a requirement) in a web application (VideoWall-like)?
Personally I'm thinking about two possible solutions, but I can't choose between them:
1) Develop a custom Firefox plugin that uses ffmpeg to acquire and decode the video streams
2) Rely on HTML5 inserting a layer between the cameras and the web application that transcodes/restreams the video streams (probably using http live streaming)
The requirements are compatibility with H.264 over RTSP and Mpeg-4 over RTP and, of course, low latency and no loss on video quality.
Thanks
Andrea
Related
We develop an IP camera product which streams H.264/MPEG4/MJPEG video via RTSP/UDP. It has a web interface, currently we use the VLC Firefox plugin to allow viewing of the live RTSP stream in the browser but Firefox are dropping support for NPAPI plugins so that's currently a dead end.
The camera itself is a relatively low-powered ARM SoC (think Raspberry Pi level) so we don't have vast spare resource to do things like transcode streams on-the-fly on the board.
The main purpose is to check the video stream is working correctly from the web interface, so streaming a new stream (or transcoding it) in some other format/transport/streaming engine is less desirable than being able to somehow play the original RTSP stream directly. In regular use the video is streamed via RTSP into a VMS server so that's not up for alteration.
In an ideal world the solution would be open-source cross-browser and happen inside an HTML5 tag, but if it works in one or more of the most popular browsers we'll take it.
I've been reading all sorts of stuff here and around the web about the brave new world of the HTML5 video tag, WebRTC, HLS, etc. and have yet to see anything that looks like a sensible and complete solution that doesn't involve some extra conversion/transcoding/re-streaming, often by some half-supported framework or an extra server in the middle which is not a viable solution.
I haven't yet found a proper description of what may or may not be required to "convert" our stream to whatever-html5-video-likes, whether it's just a slightly different wrapper around the same basic video stream or if there's a lot of overhead and everything is different. Likewise it's not clear if the conversion could be achieved either on-board or perhaps even in-browser using JS.
The reason for the title is that if we've got to change the way it all works we may as well aim to do whatever is considered "best practice" and reasonably future-proof as far as possible rather than some expedient fudge that might not work beyond the next round of browser updates / the next W3C press release...
I find it slightly disappointing (but perhaps not surprising) that in 2017 there seems to be no sensible way of achieving this.
Perhaps "least worst practice" would be more suitable terminology...
There are many methods you can use that don't require transcoding.
WebRTC
If you're using RTSP, you're much of the way there in sending your streams via WebRTC.
WebRTC uses SDP for declaring streams, and RTP for the transport of these streams. There are some other layers you need for setting up the WebRTC call, but none of these require particularly expensive computation. Most (all?) WebRTC clients will support H.264 decoding, many with hardware acceleration in-browser.
The easiest way to get started with WebRTC is to implement a browser-to-browser client first. Then, you can go a layer deeper with your own implementation.
WebRTC is the route I recommend to you. NAT traversal (in most cases) and P2P connectivity are built-in, so your customers won't have to remember IP addresses. Simply provide signalling services and your customers can connect directly to their cameras at home from wherever. Provide TURN servers, and they'll be able to connect even if both ends are firewalled. If you don't wish to provide such services, they're lightweight and can run directly on the camera in a mode like you have today.
Fragmented MP4 over HTTP Progressive with <video> tag
This method is much simpler than WebRTC, but totally different than what you're doing now. You can take your H.264 stream, and wrap it directly in an MP4 without transcoding. Then, it can be played in a <video> tag on a page. You'll have to implement the appropriate libs in your code, but here's an FFmpeg example that outputs to STDOUT, which you'd pipe to clients:
ffmpeg \
-i YOUR_CAMERA_HERE \
-vcodec copy \
-acodec copy \
-f mp4 \
-movflags frag_keyframe+empty_moov \
-
Others...
In your case, there's no added benefit to DASH. DASH is intended for utilizing file-based CDNs for streaming. You control the server, so there's no point in writing out files or handling HTTP requests in a file-like manner. While you can certainly use DASH with H.264 streams without transcoding, I think it's a waste of your time.
HLS is much the same. Your stream is compatible with HLS, but HLS is dropping out of favor rapidly due to its lack of flexibility on codec. DASH and HLS are essentially the same mechanism... write a bunch of media segments to a CDN and create a playlist or manifest indicating where they are.
Well, I had to do the same thing while back in a raspberry pi 3. we transcoded it on the fly using ffmpeg on the pi and used https://github.com/phoboslab/jsmpeg to stream mjpeg. then played it on the browser/ionic app.
var canvas = document.getElementById('video-canvas');
this.player = new JSMpeg.Player(this.button.url ,{canvas: canvas});
We were managing up to 4 concurrent streams with minimum delay <2-5 secs on our Pis.
But once we moved to React Native we used the RN VLC wrapper on the phones
I have a server that currently streams out RTMP media and I need to play it with minimum delay (2-3 seconds).
Now I'm using CRTMPServer to consume the stream but, since there is no RTMP player without flash dependency, this solutions does not work for me because I need to play it embedded into a web page.
At this point, I tried Nimble Streamer but I only could consume HLS, DASH and SLDP. HLS and DASH has 10 second delay so I discard these approaches.
SLDP has low latency but is a closed protocol and there is only one player (closed but freeware).
On the other hand, there is RTSP but there are no HTML5 players for it. But I couldn't consume RTSP streams from Nimble neither.
Any other ideas?
I do not know why you discarded Nimble Streamer, I've tried it and it has a delay of 2 or 3 seconds.
My tests were with more than 200 attendees in Full HD (1280)
And the results were incredible, it has relatively low consumption of resources, the only thing you have to take into account is the bandwidth.
They have a protocol that allows them to have a delay of 2 or 3 seconds.
Look:
https://es.wmspanel.com/nimble/sldp
So Nimble Stream seems like a good option.
regards
I'm Yury from Softvelum, which is the company behind Nimble Streamer and SLDP technology.
You mention
SLDP has low latency but is a closed protocol and there is only one
player (closed but freeware).
We currently have 3 players - HTML5/JavaScript, Android and iOS, they all are being actively developed at the moment. All 3 players have their SDKs which means you can extend their behavior in any way you like and use in your own apps and web pages. We currently communicate with other existing players in order to extend the reach of SLDP technology.
At the moment when we started creating the SLDP architecture, there were no publicly available technologies to cover low-latency last-mile scenarios while our customers strove for that all the time. That's why we implemented SLDP and our goal is not just to provide the technology but to make it available for broader audience. We cannot accomplish this by ourselves alone, hence the SDK and other initiatives. We're opened for collaboration with any other companies on this market.
If SLDP works fine for your use case, don't hesitate to use further - we have big plans for it and you can be sure it will be supported and improved by our company. Of course, your feedback is highly welcomed.
You can install one webserver with RTMP module like
Nginx+RTMP module
If have Windows 10 Pro then can use Ubuntu WSL(linux for windows) 18.04 bionic
Then can use OBS to can streaming your laptop's desktop or your laptop's webcam or other media resurse to Nginx(which have RTMP module installed)
Then as player=render you can use VLC player or can push the stream to FB,YT ... or other webservice live
OBS--->>--->NgInx(+RTMP module)--->>-->VLC player or FB,YT live
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.
I am attempting to implement a streaming audio solution for the web. My requirements are these:
Relatively low latency (no more than 2 seconds).
Streaming in a compressed format (Ogg Vorbis/MP3) to save on bandwidth.
The stream is generated on the fly and is unique for each client.
To clarify the last point, my case does not fit the usual pattern of having a stream being generated somewhere and then broadcast to the clients using something like Shoutcast. The stream is dynamic and will adapt based on client input which I handle separately using regular http requests to the same server.
Initially I looked at streaming Vorbis/MP3 as http chunks for use with the html5 audio tag, but after some more research I found a lot of people who say that the audio tag has pretty high latency which disqualifies it for this project.
I also looked into Emscripten which would allow me to play audio using SDL2, but the prospect of decoding Vorbis and MP3 in the browser is not too appealing.
I am looking to implement the server in C++ (probably using the asynchronous facilities of boost.asio), and to have as small a codebase as possible for playback in the browser (the more the browser does implicitly the better). Can anyone recommend a solution?
P.S. I have no problem implementing streaming protocol support from scratch in C++ if there are no ready to use libraries that fit the bill.
You should look into Media Source Extension.
Introduction: http://en.wikipedia.org/wiki/Media_Source_Extensions
Specification: https://w3c.github.io/media-source/
I've got a website and I've been looking for ways to embed a 24/7 webcast. I've looked at options such as Ustream and Justin.TV however, these do not work on mobile devices, which is what I really need.
I don't have that much knowledge on how streaming works but I've read that the streaming Engine Wowza is another option. I also found that HTML 5 player works cross platform and on any mobile device aswell.
If I were to use Wowza would it work with HTML 5 player? And am I even going in the right path with how I can do this. I also have a home dedicated server for streaming to a cloud wouldn't be required.
I'm very amateur just trying to broadcast my television program on my website for viewing. Any advice would help here. Thanks
Wowza can packetize video as http live streaming (HLS) which, although an Apple invention, works on most HTML5-capable browsers except IE11: http://www.jwplayer.com/html5/hls/ . Many players will fall back to using Flash for browsers which don't support native HLS or H.264 encoding. Flash uses http dynamic streaming (HDS) rather than HLS, so you would add that as another packetizer in wowza. (Wowza calls these packetizers "cupertinostreamingpacketizer" and "sanjosestreamingpacketizer" respectively.)
You would then point your preferred HTML5 video player (jwplayer, flowplayer, etc) at the URL http:// your-wowza-server.com:1935/live/yourstreamname/playlist.m3u8 [1]. For Flash fallback in flowplayer you can use the f4m resolver and the http-streaming plugin, as in the first example here, to access the subtly different URL http:// your-wowza-server.com:1935/live/yourstreamname/manifest.f4m. I'm sure something similar applies in players like jwplayer and others.
The main problem with Wowza is how much it costs: for your own server you're looking at around $55 per month per channel [2]. At least during testing, you may find it cheaper to get Wowza on Amazon EC2 devpay: $5/month rental plus an extra couple of cents per hour on your normal EC2 instance costs.
[1] Assuming you're using Wowza's default /live/ application on port 1935
[2] A channel is roughly the number of streams you're sending to the server to be re-broadcast
We developped a custom HTML5 player which we wanted to make compatible with HLS and fragmented mp4 for LIVE events. We started on Zencoder but realize they were not able to do genrate fragmented mp4.
I would like to explore the flash fallback solution and the wowza( probably on AWS) for the packaging.
Would you be available to consult on this project?
We use www.bitcodin.com for event-based or 24/7 live transcoding and streaming. It generates DASH - which can be playback natively in HTML5 using the bitdash MPEG-DASH players - as well as HLS for iOS devices. You can find an example here: http://www.dash-player.com/demo/live-streaming/