3

I am planning to do a video on demand streaming solution which will have around 500 to 1000 clicks per week. I am streaming a live event once a week via Wowza Media Server an Amazons EC2. The plan is now to have a record of that event during the week until the next live event and then override the file with the new record. Wowza is an expensive solution for 24/7 and during the week we won't have that much parallel traffic, which led me to nginx with rtmp-module. I played with it and it was no problem to a) livestream with it (RTMP/Flash only) and b) doing a video on demand stream of a file via RTMP/Flash. But for mobile devices like iOS, Android and so on I need to have a http/hls stream like Wowza does. I know it is possible to have a http/hls stream of a live event with nginx and rtmp-module. But I don't know if it is possible to have an on demand http/hls stream with nginx and rtmp-module. I couldn't find any information about that and all example configurations are only for LIVE streaming and not VoD.

Could anyone please tell me:

  1. Is VoD over http/hls possible with nginx and rtmp-module?
  2. How would an example configuration look like?
user1925121
  • 188
  • 1
  • 2
  • 9
  • Hi. Could you help with my question https://stackoverflow.com/questions/76537222/clarity-regarding-2-commands-on-publish-vs-on-play-for-nginx-rtmp – Earthling Jun 23 '23 at 05:59

2 Answers2

5

I finally tested nginx with rtmp-module for the flash and a handmaded/automated solution with a script and a cronjob and the following ffmpeg-syntax for hls:

ffmpeg -i input.m4v -acodec copy -bsf:a h264_mp4toannexb -g 105 -vcodec libx264 -vprofile baseline -bf 0 -maxrate 850k -bufsize 850k -s 960x540 -bsf:v dump_extra -map 0 -f segment -segment_format mpegts -segment_list "abc.m3u8" -segment_time 2 abc-%d.ts

note that this is for linux based systems and it is necessary to escape the % under windows like abc-%%d.ts.

user1925121
  • 188
  • 1
  • 2
  • 9
1

The nginx-rtmp module itself is open sourced, providing RTMP and live HLS streams.

However, the VOD HLS streaming is delivered only as part of their commercial solution: http://nginx.com/products/

So relatively to Nginx' support price, Wowza monthly subscription seems a better choice in terms of cost of ownership for your case.

Yury
  • 671
  • 3
  • 12
  • 2
    I don't agree with this, because HLS is possible in just any HTTP server, which are usually free. Paid Nginx support for HLS VOD is merely a convenience, because it will prepare HLS files autonomously. It is usually enough to just pre-encode HLS files using ffmpeg, and serve them like normal HTTP files. – SirDarius Nov 08 '13 at 16:50
  • 2
    Yes, pre-coding is a good option but that requires more space and also additional pre-processing to convert. That's why many businesses prefer having MP4 original files being transmuxed on the fly rather than pre-processed. But As I said, "pre-encode HLS files using ffmpeg" is a good option too. – Yury Nov 09 '13 at 00:13
  • 2
    One more thing to mention, just as a side note. The simplicity of delivery which you mention (just a set of files ready to go via any HTTP server) is the advantage which will bring binary protocols down sooner or later. Small files stored, delivered, cached (if needed) - that's the simplest thing to maintain so I'm excited that we see the streaming landscape changing rapidly to that direction. – Yury Nov 09 '13 at 00:17
  • 2
    Totally +1 to this. I'm currently reviewing options to migrate a FMS based streaming solution to a more cost-efficient and mobile-ready solution, and the recent possibilities are definitly a huge improvment. – SirDarius Nov 09 '13 at 09:44
  • 1
    When you talk about "pre-encoding HLS files" you mean generate the `ts` files and m3u8 (with ffmpeg) and just server the m3u8 which will include all the fragments (rather than the most recent N as happens in live streaming)...? Basically the nginx-rtmp HLS section doesn't serve HLS it just creates HLS fragments which you then serve via the http server. Do I have this right? – Hari Honor Oct 29 '20 at 14:05