We are developing an application, where we required to load the rtsp video into the browser without using any poxy.
We tried to VLC Plugin but it only supports for the ie browser.
I am not aware of any browser which natively support RTSP streams at this time.
The usual approach is to use a proxy or a streaming server to covert the steams to something like HLS or DASH, but you say you can't do that.
There does exist a VLC browser plugin which certainly did support this (not tested it recently) but it does not include support for chrome which may rule it out if you are looking for cross browser support:
https://wiki.videolan.org/Documentation%3aWebPlugin/
I have a backend streaming video to web browsers using RTMP. On the browsers we use jwplayer.
As everybody know flash player is going to be deprecated soon.
Im looking for options to modify the backend using another streaming solution.
We have made some test using DASH but it has too much delay for live streamining compared to RTMP.
What are the options for anyone using RTMP ?
I have been doing a lot of research into WebRTC for a project I am currently working on. I am aware that it is only supported in Chrome, Firefox, and now Opera. However, I am wondering if their is a cross-browser viewer solution that does not require a plugin. This way I could require that broadcasts be done from a webRTC compliant browser but viewers could use other browsers such as Safari or IE with watching/viewing capabilities only.
The application I am working on is used for small group broadcasts of 25 or less people with a single publisher/presenter.
Here is a list of the options/ideas so far.
Somehow have a html5 canvas element display the frames of the video on non-webRTC supported browsers. However, I also need to support audio as well and I don't believe there is anyway as of right now to feed the audio stream into the HTML5 audio element. This option may be dead before it is even considered...
Have a server subscribe to the webrtc stream and then create a HLS (HTTP Live Stream) stream that can then be consumed by a browser player (Possibly Flowplayer, it supports cross-browser HLS to the best of my knowledge). I have found that Web Call Server 4 from the guys at Flashphoner can do the conversion to HLS but it seems like overkill for a simple server that does the WebRTC to HLS conversion. Hoping that there may be some sort of node.js implementation out there to generate the playlist and files for HLS so there is low latency.
Any help from the community on this would be much appreciated. The question is pretty specific and I have been researching solutions for the last 2 months so I think it warrants a stack overflow post at this point.
-- UPDATE
There may be a 3rd option here, having users on non-webrtc supported browsers install a plugin. This would only be for Safari and IE but it may be a solution. One free plugin that can be distributed for an app based on my findings are [link]https://github.com/sarandogou/webrtc-everywhere It may be possible to use this plugin with something like Kuento for signalling and achieve a solution that will at least work on all desktop browsers until Safari and IE catch-up with WebRTC.
I'm trying to figure out if web based audio streaming sites use the Web Audio API for playback or if they rely on the audio element or something else.
Since the user of an audio streaming service typically doesn't need more functionality than starting and stopping the audio, then I guess that the audio element is enough. If a VU-meter is required then I would guess the Web Audio API would be used since it has an built in analyser node. But since IE doesn't support the API then I suppose you'd rather use the audio element and reach the IE users than using fancy extras such as an VU-meter.
I've been looking at the source code for Spotifys web player, Grooveshark, BBC radio and the Polish public radio but I find neither audio elements or use of the Web Audio API. I did find that the Swedish public radio (sr.se) makes use of the audio element though.
I'm not asking for anyone to go through the JavaScript source code for me, but rather if someone who is familiar with the subject could point me in the right direction.
I don't know of any internet radio services playing back their streams with the Web Audio API currently, but I wouldn't be surprised to find one. I've been working on one myself using Audiocog's excellent Aurora.js library, which enables codecs in-browser that wouldn't normally be available, by decoding the audio with JavaScript. However, for compatibility reasons as you have pointed out, this would be considered a bit experimental today.
Most internet radio stations use progressive HTTP streaming (SHOUTcast/Icecast style) which can be played back within an <audio> element or Flash. This works well but can be hard to get right, especially if you use SHOUTcast servers as they are not quite 100% compatible with HTTP, hurting browser support in some versions of Firefox and a lot of mobile browsers. I ended up writing my own server called AudioPump Server to get better browser and mobile browser support with HTTP progressive.
Depending on your Flash code and ActionScript version available, you might also have to deal with memory leaks in creative ways, since by default Flash will keep all of your stream data in memory indefinitely as it was never built to stream over HTTP. Many use RTMP with Flash (with Wowza or similar on the server), which Flash was built to stream with to get around this problem.
iOS supports HLS which is basically a collection of static files served by an HTTP server. The encoder writes a chunk of the stream to each file as the encoding occurs, and the client just downloads them and plays them back seamlessly. The benefit here is that the client can choose a bitrate to stream and, raising quality up and down as network conditions change. This also means that you can completely switch networks (say from WiFi to 3G) and still maintain the stream since chunks are downloaded independently and statelessly. Android "supports" HLS, but it is buggy. Safari is the only browser currently supporting HLS.
Compatibility detection is not something you need to solve yourself. There are many players, such as jPlayer and JW Player which wrangle HTML5 audio support detection, codec support detection, and provide a common API between playback for HTML5 audio and Flash. They also provide an optional UI if you want to get up and running quickly.
Finally, most stations do offer a link to allow you to play the stream in your own media player. This is done by linking to a playlist file (usually M3U or PLS) which is downloaded and often immediately opened (as configured by the user and their browser). The player software loads this playlist and then connects directly to the streaming server to begin playback. On Android, you simply link to the stream URL. It will detect the Content-Type response header, disconnect, and open its configured media player for playback. These days you have to hunt to find these direct links, but they are out there.
If you ever want to know what a station is using without digging around in their compiled and minified source code, simply use a tool like Fiddler or Wireshark and watch the traffic. You will find that it is very straightforward under the hood.
We use Web Audio for streaming via Aurora.js using a protocol very similar to HTTP Live Streaming. We did this because we wanted the same streaming backend to serve iPhone, Android and the web.
It was all a very long and painful process that took over 6 months of effort, but now that its all finished, its all good.
Have a look at http://radioflote.com and feel free to shoot questions or clarifications regarding anything. Go ahead and disassemble the code if you want to. Not a problem.
I'm building a web app that should play back an RTSP/RTP stream from a server http://lscube.org/projects/feng.
Does the HTML5 video/audio tag support the rtsp or rtp? If not, what would the easiest solution be? Perhaps drop down to a VLC plugin or something like that.
Technically 'Yes'
(but not really...)
HTML 5's <video> tag is protocol agnostic—it does not care. You place the protocol in the src attribute as part of the URL. E.g.:
<video src="rtp://myserver.com/path/to/stream">
Your browser does not support the VIDEO tag and/or RTP streams.
</video>
or maybe
<video src="http://myserver.com:1935/path/to/stream/myPlaylist.m3u8">
Your browser does not support the VIDEO tag and/or RTP streams.
</video>
That said, the implementation of the <video> tag is browser specific. Since it is early days for HTML 5, I expect frequently changing support (or lack of support).
From the W3C's HTML5 spec (The video element):
User agents may support any video and audio codecs and container formats
The spirit of the question, I think, was not truly answered. No, you cannot use a video tag to play rtsp streams as of now. The other answer regarding the link to Chromium guy's "never" is a bit misleading as the linked thread / answer is not directly referring to Chrome playing rtsp via the video tag. Read the entire linked thread, especially the comments at the very bottom and links to other threads.
The real answer is this: No, you cannot just put a video tag on an html 5 page and play rtsp. You need to use a Javascript library of some sort (unless you want to get into playing things with flash and silverlight players) to play streaming video. {IMHO} At the rate the html 5 video discussion and implementation is going, the various vendors of proprietary video standards are not interested in helping this move forward so don't count of the promised ease of use of the video tag unless the browser makers take it upon themselves to somehow solve the problem...again, not likely.{/IMHO}
This is an old qustion, but I had to do it myself recently and I achieved something working so (besides response like mine would save me some time):
Basically use ffmpeg to change the container to HLS, most of the IPCams stream h264 and some basic type of PCM, so use something like that:
ffmpeg -v info -i rtsp://ip:port/h264.sdp -c:v copy -c:a copy -bufsize 1835k -pix_fmt yuv420p -flags -global_header -hls_time 10 -hls_list_size 6 -hls_wrap 10 -start_number 1 /var/www/html/test.m3u8
Then use video.js with HLS plugin This will play Live stream nicely There is also a jsfiddle example under second link).
Note: although this is not a native support it doesn't require anything extra on user frontend.
There are three streaming protocols / technology in HTML5:
Live streaming, low latency
- WebRTC
- Websocket
VOD and Live streaming, high latency
- HLS
1. WebRTC
In fact WebRTC is SRTP(secure RTP protocol).
Thus we can say that video tag supports RTP(SRTP) indirectly via WebRTC.
Therefore to get RTP stream on your Chrome, Firefox or another HTML5 browser, you need a WebRTC server which will deliver the SRTP stream to browser.
2. Websocket
It is TCP based, but with lower latency than HLS. Again you need a Websocket server.
3. HLS
Most popular high-latency streaming protocol for VOD(pre-recorded video).
Chrome will never implement support RTSP streaming.
At least, in the words of a Chromium developer here:
we're never going to add support for this
With VLC i'm able to transcode a live RTSP stream (mpeg4) to an HTTP stream in a OGG format (Vorbis/Theora). The quality is poor but the video work in Chrome 9.
I have also tested with a trancoding in WEBM (VP8) but it's don't seem to work (VLC have the option but i don't know if it's really implemented for now..)
The first to have a doc on this should notify us ;)
Chrome not implement support RTSP streaming.
An important project to check it WebRTC.
"WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs"
Supported Browsers:
Chrome, Firefox and Opera.
Supported Mobile Platforms:
Android and IOS
http://www.webrtc.org/
Years past, there are some updates about RTSP in H5:
RTSP is not supported in H5, neither PC nor mobile.
Flash is disabled in Chrome, see Adobe
MSE works good except iOS safari, for flv.js to play HTTP-FLV on H5, or hls.js to play HLS on H5.
WebRTC is also a possible way to play streaming in H5, especially in 0.2~1s latency scenarios.
Note: I think it's because RTSP use TCP signaling protocol to exchange SDP, which is not HTTP in H5 so it's really hard to support it, especially there is WebRTC now.
So, if you could transcode RTSP to other protocols, like HTTP-FLV/HLS/WebRTC, then you could use H5 to play the stream. Recommend to use FFmpeg to do the transcode:
ffmpeg -i "rtsp://user:password#ip" -c:v libx264 -f flv rtmp://server/live/stream
Start a RTMP server like SRS to accept the RTMP and transmux to HTTP-FLV, HLS and WebRTC:
./objs/srs -c conf/rtmp2rtc.conf
Then it's OK to play the stream by:
HLS by video or hls.js: http://server:8080/live/stream.m3u8
HTTP-FLV by flv.js: http://server:8080/live/stream.flv
WebRTC by H5 or native SDK: webrtc://server:1985/live/stream
Note that the latency of HLS is about 5~10s, LLHLS is better but not too much. The HTTP-FLV is about 1~3s, very similar to RTMP. And the WebRTC latency is about 0.2s, while if covert RTSP to RTMP to WebRTC the latency is about 0.8s.
My observations regarding the HTML 5 video tag and rtsp(rtp) streams are, that it only works with konqueror(KDE 4.4.1, Phonon-backend set to GStreamer). I got only video (no audio) with a H.264/AAC RTSP(RTP) stream.
The streams from http://media.esof2010.org/ didn't work with konqueror(KDE 4.4.1, Phonon-backend set to GStreamer).
Putting a conclusion as of now.
I am trying to build a way around it meaninglessly since rtsp doesn't work OOB. Without a "manager" handling the streaming to be perfected to the way a video tag works, it's not possible now.
I am currently working on something around android+html (hybrid) solution to manage this in a very wicked way. Since it is supposed to play directly from camera to android with no intermediary servers, we came up with a solution involving canvas tag to bridge the non-webview with the webview.