live streaming

[jAndreas]

Hello, I'm quite new to the nginx-vod-module. So far I only used it for serving static mp4-video as HLS data to clients. Can somebody link me an example of how to configure the vod module to serve live content? How would this work together if you have a server-process which continuously receives video data from a client? Does this process just write that binary data into a mp4-file and you link that file by using vod_upstream_location for instance?

I guess my real question is, if nginx can (should) be used in that way. The input stream is raw binary data from any html5-capable browser, sending blob-chunks to my server, which in turn I want to broadcast and therefore stream. Is this a valid case for the nginx vod module? Or should I instead use ffmpeg to read the input data (or file data)?

[davidoster]

Check this: nginx-rtmp-module

[jessp01]

And this: https://blog.kaltura.com/free-and-open-live-video-streaming :)

[jAndreas]

Is there any advantage in using nginx instead of ffmpeg directly, when I just want to create a live HLS stream (segments)? ffmpeg can do this very well on its own afaik. To publish a stream to a wider audience, it would be wise choice to re-stream whatever content to a network like Wowza for instance?

[jessp01]

Hi @jAndreas,

The FFmpeg project does include a component called ffserver, however, see: https://ffmpeg.org:

July 10th, 2016, ffserver program being dropped After thorough deliberation, we're announcing that we're about to drop the ffserver program from the project starting with the next release. ffserver has been a problematic program to maintain due to its use of internal APIs, which complicated the recent cleanups to the libavformat library, and block further cleanups and improvements which are desired by API users and will be easier to maintain. Furthermore the program has been hard for users to deploy and run due to reliability issues, lack of knowledgable people to help and confusing configuration file syntax. Current users and members of the community are invited to write a replacement program to fill the same niche that ffserver did using the new APIs and to contact us so we may point users to test and contribute to its development.

So I wouldn't recommend using it. You can of course use Wowza if you wish [at Kaltura we do make use of it for certain functions in our SaaS ENV] but if you want a FOSS, scalable solution, I can certainly recommend the Nginx RTMP module. As you can gather from the post I mentioned in my prev reply, this is used by our Kaltura CE and we've been very pleased with it. It especially makes sense if you're already utilising Nginx for other purposes, which I gather you are since you posted here:)

[erankor]

I think this question is more appropriate for the nginx-rtmp-module repo, but IMHO it depends on the use case. If there is no transcoding involved, and you just want to package the RTMP to HLS, I think nginx-rtmp-module will probably be much more efficient. Maybe you don't have many streams, so it's not relevant, but I'd expect that a server running nginx-rtmp-module will be able to repackage significantly more streams than ffmpeg. If you need to transcode the video stream (e.g. in order to produce lower quality renditions) then it doesn't matter, since in both cases the transcoding is done by ffmpeg, and the repackaging is negligible compared to the load of transcoding.

[jAndreas]

Thanks for the response and input, helped me a lot. Ultimately my own server which is running nginx, ffmpeg (or both in combination) acts just like a middleware, doesn't it? Both nginx (rtmp module) and ffmpeg have to re-stream (forward) the input data (transcoded or not) to a network cluster which can handle hundreds or thousands of viewers right? So the only question left is, if nginx with rtmp- and probably vod-module has a significant performance impact over directly using ffmpeg to transcode the input data and forward it to broadcast-cluster like wowza?

Or do I somehow totally misunderstand the concept of rtmp? That module is limited to the available bandwidth my server is connected to right?

[davidoster]

@jAndreas Well what you mention here is something that needs detailed specification. But let's be clear of a couple of things. Nginx is a really optimized piece of software and the same goes for the ffmpeg process. For transcoding you need ffmpeg on top of nginx. That means that you have 2 processes that run in order to get the transcoded stream to the viewer. How fast is the above process depends on the source stream (quality wise) and how fast is your hardware and all this counts towards the speed that the resulting stream is served, how long it takes before it starts to stream. On top of that you have any network (internet) latency you get between the edge server (the one that serves the stream) and the viewer. And for the fun part let's see about the number of concurrent viewers. This can actually be calculated in pretty simple terms,

assume 1200KBps of low HD video quality that is 1.2 MBps of bandwidth.

1000MBps (1GBps network socket connection) / 1.2MBps video quality = 833 concurrent viewers but in order to be on the safe side we don't want to go more than 750 concurrent viewers.

So, for example on a Scaleway server (I chose this because it doesn't give you a bandwidth restriction!) of C1 type you have, 200MBps / 1.2MBps video quality = 166 concurrent viewers or 130 for being on the safe side!

If you manage to do load balancing in front of your edge servers and split the traffic to several servers then well done you have made your own custom!!! CDN solution, otherwise you need to go for professional CDN services!

[erankor]

@jAndreas, from your question, I think you may be confusing the use of RTMP for publishing vs. using RTMP for playback. RTMP can do both, but with the decay of flash, it's hardly used for playback these days, for publishing it's still dominant. If you don't use RTMP for playback, you will most likely use HLS/DASH. These protocols are HTTP based, so they can be delivered transparently by CDNs / caching proxies (that is not the case with RTMP). So, once you repackaged the RTMP to HLS/DASH (whether using nginx-rtmp-module / ffmpeg / wowza etc.) you no longer need a streaming server - you just need plain HTTP caching proxies. If you have many viewers or if your viewers are spread geographically, I'd recommend that you use some CDN (Akamai/Level3/etc.), as @davidoster wrote above. If your viewers are clustered and there aren't too many of them, you can set up a few caching proxies, my personal preference is nginx, but you can use varnish/squid/whatever If you have very few users, you can have them play directly from the streaming server.