I am an absolute beginner with this. I installed Wowza and wanted to play VOD. The test works, the sample.mp4 plays. However when I try what looks like the same URL shown in the test player, which in my case is:
http://192.168.5.76:1935/voddec8/mp4:sample.mp4/manifest.f4m
I get the contents of the manifest. When I try to remove the manifest.f4m so that the URL is just:
http://192.168.5.76:1935/voddec8/mp4:sample.mp4
EDIT: Could it be that I need to be in a player, not a browser?
I just get info about the Wowza server:
Wowza Streaming Engine 4 Trial Edition (Expires: Jun 07, 2016) 4.3.0 build16025
What am I doing wrong?
Wowza does not support progressive download (meaning basic http download), you can do that with any web server. Then you could open something like this in the browser http://192.168.5.76:1935/voddec8/sample.mp4
If you want to play an HLS stream (playlist.m3u8) or HDS (manifest.f4m) you need to call it through a player that supports those protocols, like Jwplayer, Flowplayer,... or an application like VLC. Mobile devices (iphones, and moder Android should open HLS stream directly though.
You can also open the stream using rtmp, but you need a player (flash based) using an url like this rtmp://192.168.5.76:1935/voddec8/mp4:sample.mp4
You need to check what is the protocol best suited for you.
if you want to deliver the vod as progressive method , you can try nimble streamer (wmspanel.com)
which will gives you additional security for progressive delivery method, and if this is for web delivery i prefer to deliver using hls method (.m3u8) which is the best method to avoid your sever bandwidth also.
If you have installed wowza on local system, the URL pattern will be your IP address. You can switch wowza to listen on any port (should be open port).
Ex: rtmp://10.136.15.1:1935/vod/mp4:bunny.mp4
Instead of running it under 1935, you can switch it to listen on port:80.
You can try running your vod video in VLC player, as highlighted below.
Once this is running, you can embed it in your application using open source media player (strobe player) : http://matbury.com/strobe/
Related
I don’t know if I can say “I’m sorry for ask” but I spent more than a week looking for a solution without success. I have a Jetson Nano and with OpenCV I get and process an image at 4fps, I need to send this video to a web server to allow the client connected to the server get the video. Everything need to be written in C++.
Because a need a low latency I did test with GStreamer and WebRTC without success. I don’t have any web server ready, so I can use any implementation.
Anyone know where I can find some example implementation with this schema?
You can use mediasoup to send data to the server to then send the stream with rtp to another endpoint like gstreamer or ffmpeg.
Here is a recording project where data is sent from the browser -> server -> gstreamer -> file.
Mediasoup is written in c++ and has a wrapper for js.
I had similar problem and used such example from GStreamer WebRTC official repo. It's written in Python for Janus Gateway video rooms but I think it can be easily rewritten in C++ as you need.
In the code for OpenCV, I used V4L2Loopback as a virtual output device to be used as input for GStreamer WebRTC example.
I hope such approach may help you.
I think no need to send it to a Web Server. In Gstreamer examples [https://github.com/GStreamer/gst-examples]. The SendOnly example sends a video to a Web Client Using WebRTC. You can modify it to send an OpenCV mat.
I am working on a live-streaming prototype, I have been reading a lot about how live-streaming works and many different approaches but I still can't find a live-streaming stack that suits my needs...
These are the requirements for my prototype:
1)The video/audio recording must come from a web browser using the webcam, the idea is that the client preferably shouldn't need to install plugins or do anything complicated(maybe installing Flash player plugin is acceptable, only for recording the video, the viewers should be able to view the stream without plugins).
2)It can't be peer to peer since I also need to store the entire video in my server (or in Amazon s3 servers for example) for viewing later.
3)The viewers should also be able to watch the stream without the need of installing anything, from their web browsers, say Chrome and Firefox for example. We want to use the HTML5 video tag if possible.
4)The prototype should be constructed without expending money preferably. I have seen that AWS-Cloudfront and Wowza offer free trials so we are thinking about using these 2 services.
5)The prototype should be able to maintain 1 live stream at a time and 2 viewers, just that, so there are no restrictions regarding this.
Any suggestions?
I am specially stuck/confused with the uploading/encoding video part of the architecture(I am new to streaming and all the formats/codecs/protocols/technologies are making it really hard to digest).
As of right now, I came across WebRTC that apparently allows me to do what I want, record and encode video from the browser using the webcam, but this API only works with HTTPS sites. Are there any alternatives that work with HTTP sites?
The other part that I am not completely sure about is the need for an encoding server, for example Wowza Streaming Engine, why do I need it? Isn't it enough if I use for example WebRTC for encoding the video and then I just send it to the distribution service (AWS-Cloudfront for example)? I do understand that the encoding server would allow me to support many different devices since it will create lots of different encodings and serve many different HTTP protocols, but do I need it for this prototype? I just want to make a 1 format (MP4 for example) live-stream that can be viewed in 2 web browsers, that's all, I don't need variety of formats nor support for different bandwidths or devices.
Base on your requirement, WebRTC is good way.
API only works with HTTPS sites. Are there any alternatives that work
with HTTP sites?
No. Currently Firefox is only browser is allow WebRTC on HTTP, but finally it need HTTPS
For doing this prototype you need to go with the Wowza WebRTC.
While going with wowza all the streams are delivered from the wowza only.So it become a routed WebRTC.
Install Wowza - https://www.wowza.com/docs/how-to-install-and-configure-wowza-streaming-engine
Enable the WebRTC - https://www.wowza.com/docs/how-to-use-webrtc-with-wowza-streaming-engine
Downaload and configure the Streamlock. or Selfsigned JKS file - https://www.wowza.com/docs/how-to-request-an-ssl-certificate-from-a-certificate-authority
Download the sample WebRTC - https://www.wowza.com/_private/webrtc/
Publish stream using the Publish HTML and Play through the Play HTML ( Supported Chrome,Firefox & Opera Browsers)
For MP4 files in WebRTC : you need to enable the transcoder with h264 & aac. Also you need to enable the option Record all the incoming Streams in the properties of application which you are creating for the WebRTC ( Not the DVR ).Using the File writer module save all the recorded files in a custom location.By using a custom script(Bash,Python) Move all the Transcoded files to the s3 bucket, Deliver through cloudfront.
I have small computer (something like Arduino or Raspberry pi) with Linux, camera and gstreamer installed on it.
I need to stream h264 video from this device to browser using WebRTC technology. Also, I use NodeJS as signaling server.
In simple words, I need to doing a WebRTC client from my device. What is the best way to do this? Can I use WebRTC Native API for this goal? How can I install it on my small device? Or, maybe, I just need to play with my gstreamer and install some webrtc plugins for it?
Since you will have to use a signalling server anyways, I would say you should use the Janus-Gateway. You mention CentOS for your signalling server, I am not 100% if it will run on CentOS specifically, but I have ran it successfully in Debian Jessie build with just a few dependency installations.
Janus handles the entire call set up with the gateway(signalling and everything). So, some port forwarding will probably have to be done so that the SDP exchange can occur(which you would have to worry about with any signalling server).
Install the gateway, there are a few dependencies but all were simple
installations
Take a look at the janus_streaming plugin. It has a gstreamer example that will stream from a gstreamer pipeline. Also, the streamingtest demo page to see how the Javascript API works for that plugin
The plugin listens on those ports given in the configuration file and will accept traffic from any IP address. So, I expect you can run a gstreamer pipeline on a different machine on the same network and send it to the plugin.
NOTE: You will have to modify the SDP that the JavaScipt sends to the gateway so that it includes H264(probably get rid of all other codecs as well just to force negotiation). You can do this by accessing the sdp through the jsep object passed to the success case for the createOffer function in the janus JavaScript API(jsep.sdp).
Another possibility for you is to use the Kurento Media Server (KMS), which has been written on top of GStreamer. I see two possibilities
You install KMS in a Ubuntu 14.04 box and bridge with your device, so that the device generates the video stream and sends it to the KMS box. From that, you can transcode it to VP9 and distribute it as a WebRTC stream quite easily using kurento client APIs (which may be used from Node.js). The application making the transcoding will require an RtpEndpoint (receiving video form the device in RTP/H.264) connected to a WebRtcEndpoint (capable of sending the video stream through WebRTC). This option is quite simple to implement because it's the standard way of using KMS. However, you will need to generate the RTP/H.264 stream on the device and appropriate SDP for it (this can be done using standard GStreamer elements)
You try to install KMS into your box directly. This might be more complex because it requires compiling KMS to the specific device, which may require some time investment. In addition, performing the transcoding in the device might be too expensive and you could starve its CPU.
Disclaimer: I'm member of the Kurento development team
You mentioned that you used a NodeJS signaling server. Recently Ericsson released an open source WebRTC gstreamer element: http://www.openwebrtc.io/, and along with their release they also published a WebRTC demo using node.js: http://demo.openwebrtc.io:38080/; the code here: https://github.com/EricssonResearch/openwebrtc-examples/tree/master/server.
For WebRTC for Raspberry Pi 2 you may want to consider UV4L. It allows you to stream live Audio & Video from the Rpi to any browser on a PC (HTML5).
Do you guys have any suggestions on free/paid solutions for recording video from webcam and storing it on the wowza media server? I tried the wowza recording example but I couldn't figure out how I can set the server connection as a variable.
Thanks!
Try HDFVR, a paid flash application, but very good.
The wowza recording example should work for this. When you say you couldn't "figure out how to set the server connection as a variable", is that from the client to tell Wowza to record, or to play back the already recorded stream? Using the built-in http provider here http://www.wowza.com/forums/content.php?123 will allow you to make post requests to the Wowza server to start and stop recording.
I would like to be able to stream media content originated by eg. a file to a flash player using RTMP.
I have considered librtmp though it seems ffmpeg support rtmp more as a client than as a server, that is, it implement the push/pull models w/o a ~server~ model.
Having 'ffserver' in mind, Does it support RTMP in the above mentioned manner? is it possibe to expose H264/AAC content via RTMP using ffserver ?
Any help will B appreciated.
Nadav at Sophin
Have you looked into Red5? http://www.red5.org/
I have used CRTMP-Server and have to say its amazing, and C/C++
http://www.rtmpd.com/
it worked great for me. I used to to send a MPEG-TS stream to a flash client. for a live desktop capture application.
Basically i had a directshow filter that captured the desktop area, then fed it to a H264 encoder filter then wrapped it in a TS container and fed it via TCP to rtmpd. It worked pretty well.