5 ms·

As a general comment on how you can do this sort of thing super minimally: You can use ffmpeg on the command line to transcode anything it can read (including

As a general comment on how you can do this sort of thing super minimally: You can use ffmpeg on the command line to transcode anything it can read (including streams) to an HLS playlist + segments, and serve those HLS playlist + segments statically using any HTTP server. Then you can write a simple HTML page that uses a video player to play it back in a browser. I used this to create a simple dashboard page for my home security cams (they provide an RTMP stream I can feed right into ffmpeg) after I got sick of the software I had eating too much CPU (I use '-v:copy -a:copy', so no actually re-encoding happens). Obviously, this owncast is cool for probably being easier to setup, definitely better looking, and having more features, like chat. I just wanted convey there's nothing magic to doing your own streaming video. More people should do it instead of feeding into the YouTube/Twitch behemoths and untrustworthy cloud IoT stuff.

jarbus 6y ago
This is really cool, thanks for pointing this out. Definitely a different use-case but never knew it was this simple to stream video.
suyash 6y ago
For video streaming I would prefer to use WebRTC over RTMP
- cghendrix 6y ago
  As someone who doesn’t know much about the two protocols: how come?
  - suyash 6y ago
    Here is a good answer https://www.quora.com/Which-is-better-for-live-streaming-RTMP-vs-HLS-vs-WebRTC https://www.quora.com/Which-is-better-for-live-streaming-RTM...
  - manishsharan 6y ago
    I guessing it's because Webrtc is near real-time whereas transcoding to HLS would add latency. However the advantage of HLS is that you can offload the serving of the content to a CDN or a Http server and scale horizontally. Whereas serving more webrtc clients would require fatter/bigger webrtc server. Please note I am only basing my opinion base on what I have read on HN.
  - dkh 6y ago
    WebRTC is amazing and definitely has its uses in video streaming, but it does present a number of challenges and disadvantages. Simplified, it can have lower latency and higher reliability, but at the cost of compatibility and scalability. (Also, "higher reliability" takes a lot of work to implement properly, whereas out-of-the-box for most users it would likely be lower reliability.) For the use-cases mentioned about home security cameras and other personal or low-volume situations where you also have knowledge of and control over the playback devices, sure, you can get away with it no problem. But if you are building a streaming platform for public consumption or something, we just aren't there yet. Delivering video over WebRTC to tons of clients is much more complex than serving them chunked flat files. With HLS/DASH, your clients are just downloading tiny video files over HTTP, and they can be live or be served up by anywhere -- nginx, S3, anything. It's not much different on the server-side than how file serving has always been. WebRTC though requires each client to be connected in constant 2-way communication with the server, and the logic/work the server has to do goes up tremendously since it will be attempting to chop up and serve the exact number of bytes of video each individual client needs on-the-fly rather than each client getting the same identical 1- to 4-second chunks. This presents even more challenges if your clients are at different parts of the stream, have crappy bandwidth, etc. In terms of compatibility, WebRTC is widely prevalent, but not nearly the same as HLS/DASH. Many clients that do support it have their own quirks, limitations, etc. that need to be catered to slightly differently, especially on mobile devices. For these reasons and others, you currently see WebRTC used for broadcast right now mostly at the scale of dozens to maybe hundreds, but not more than that. What WebRTC is very useful for is p2p. It has enabled things like WebTorrent to have users be serving video to peers while they are themselves watching, reducing strain/cost on the provider. It is also clearly beneficial for things like conference calls, where there is a small number of clients talking to each other multidirectionally.
- bronco21016 6y ago
  In the case of home security cams, WebRTC is generally not an option. If it was I’m sure we would have a slew of new browser based monitoring solutions.
manishsharan 6y ago
I wonder how much latency is added in when you feed the RTMP into ffmpeg. Why not just plain old webrtc with the viewing clients muted.
- SahAssar 6y ago
  Not many security cams support webrtc and if doing broadcast (and the server is directly reachable) HLS or MPEG-DASH is usually more efficient anyway since plain file serving is simpler and can be cached/optimized in ways that are harder for protocols like webrtc. HLS/MPEG-DASH are higher latency, but that can be reduced to a few seconds or less with tradeoffs.
  - dkh 6y ago
    There are also things like LL-HLS and others coming down the pipeline that will further reduce latency issues with a lot less complexity than WebRTC. (Maybe not for the security camera not-many-viewers use-case, but certainly for anything being watched by a lot of people)
throwaway3031 6y ago
this is spot on - I attempted to create an adult entertainment site and this was the crux of it. The security aspect of the entire architecture is a whole different endeavor.
craftkiller 6y ago
If you use nginx as your http server then you don't need ffmpeg to cut up your RTMP streams, the nginx rtmp module will read RTMP streams and serve RTMP, HLS, and DASH. Throw the stream module in front of it and you can do RTMPS.
- schoolornot 6y ago
  Was this plugin recently re-licensed from paid to open source?
  - gallexme 6y ago
    It was included in nginx plus subscription as far as I remember
  - craftkiller 6y ago
    The source is available here under a BSD style license: https://github.com/arut/nginx-rtmp-module https://github.com/arut/nginx-rtmp-module I don't know the paid/OS history of the module but all I had to do to get it was check a checkbox on FreeBSD since it was configured as an option in the port.
madamelic 6y ago
Ah, yes. The Dropbox comment!
- SahAssar 6y ago
  The parent comment seems a lot more understanding to different use-cases than the classic dropbox comment. It even ends with > Obviously, this owncast is cool for probably being easier to setup, definitely better looking, and having more features, like chat. I just wanted convey there's nothing magic to doing your own streaming video. Mentioning the dropbox comment seems to have become a way to dismiss comments without actually replying to them.
russdpale 6y ago
for the average person, all of those things you listed might as well be magic.

jarbus 6y ago

This is really cool, thanks for pointing this out. Definitely a different use-case but never knew it was this simple to stream video.

suyash 6y ago

For video streaming I would prefer to use WebRTC over RTMP

cghendrix 6y ago
As someone who doesn’t know much about the two protocols: how come?
- suyash 6y ago
  Here is a good answer https://www.quora.com/Which-is-better-for-live-streaming-RTMP-vs-HLS-vs-WebRTC https://www.quora.com/Which-is-better-for-live-streaming-RTM...
- manishsharan 6y ago
  I guessing it's because Webrtc is near real-time whereas transcoding to HLS would add latency. However the advantage of HLS is that you can offload the serving of the content to a CDN or a Http server and scale horizontally. Whereas serving more webrtc clients would require fatter/bigger webrtc server. Please note I am only basing my opinion base on what I have read on HN.
- dkh 6y ago
  WebRTC is amazing and definitely has its uses in video streaming, but it does present a number of challenges and disadvantages. Simplified, it can have lower latency and higher reliability, but at the cost of compatibility and scalability. (Also, "higher reliability" takes a lot of work to implement properly, whereas out-of-the-box for most users it would likely be lower reliability.) For the use-cases mentioned about home security cameras and other personal or low-volume situations where you also have knowledge of and control over the playback devices, sure, you can get away with it no problem. But if you are building a streaming platform for public consumption or something, we just aren't there yet. Delivering video over WebRTC to tons of clients is much more complex than serving them chunked flat files. With HLS/DASH, your clients are just downloading tiny video files over HTTP, and they can be live or be served up by anywhere -- nginx, S3, anything. It's not much different on the server-side than how file serving has always been. WebRTC though requires each client to be connected in constant 2-way communication with the server, and the logic/work the server has to do goes up tremendously since it will be attempting to chop up and serve the exact number of bytes of video each individual client needs on-the-fly rather than each client getting the same identical 1- to 4-second chunks. This presents even more challenges if your clients are at different parts of the stream, have crappy bandwidth, etc. In terms of compatibility, WebRTC is widely prevalent, but not nearly the same as HLS/DASH. Many clients that do support it have their own quirks, limitations, etc. that need to be catered to slightly differently, especially on mobile devices. For these reasons and others, you currently see WebRTC used for broadcast right now mostly at the scale of dozens to maybe hundreds, but not more than that. What WebRTC is very useful for is p2p. It has enabled things like WebTorrent to have users be serving video to peers while they are themselves watching, reducing strain/cost on the provider. It is also clearly beneficial for things like conference calls, where there is a small number of clients talking to each other multidirectionally.
bronco21016 6y ago
In the case of home security cams, WebRTC is generally not an option. If it was I’m sure we would have a slew of new browser based monitoring solutions.

manishsharan 6y ago

I wonder how much latency is added in when you feed the RTMP into ffmpeg. Why not just plain old webrtc with the viewing clients muted.

SahAssar 6y ago
Not many security cams support webrtc and if doing broadcast (and the server is directly reachable) HLS or MPEG-DASH is usually more efficient anyway since plain file serving is simpler and can be cached/optimized in ways that are harder for protocols like webrtc. HLS/MPEG-DASH are higher latency, but that can be reduced to a few seconds or less with tradeoffs.
- dkh 6y ago
  There are also things like LL-HLS and others coming down the pipeline that will further reduce latency issues with a lot less complexity than WebRTC. (Maybe not for the security camera not-many-viewers use-case, but certainly for anything being watched by a lot of people)

throwaway3031 6y ago

this is spot on - I attempted to create an adult entertainment site and this was the crux of it. The security aspect of the entire architecture is a whole different endeavor.

craftkiller 6y ago

If you use nginx as your http server then you don't need ffmpeg to cut up your RTMP streams, the nginx rtmp module will read RTMP streams and serve RTMP, HLS, and DASH. Throw the stream module in front of it and you can do RTMPS.

schoolornot 6y ago
Was this plugin recently re-licensed from paid to open source?
- gallexme 6y ago
  It was included in nginx plus subscription as far as I remember
- craftkiller 6y ago
  The source is available here under a BSD style license: https://github.com/arut/nginx-rtmp-module https://github.com/arut/nginx-rtmp-module I don't know the paid/OS history of the module but all I had to do to get it was check a checkbox on FreeBSD since it was configured as an option in the port.

madamelic 6y ago

Ah, yes. The Dropbox comment!

SahAssar 6y ago
The parent comment seems a lot more understanding to different use-cases than the classic dropbox comment. It even ends with > Obviously, this owncast is cool for probably being easier to setup, definitely better looking, and having more features, like chat. I just wanted convey there's nothing magic to doing your own streaming video. Mentioning the dropbox comment seems to have become a way to dismiss comments without actually replying to them.

russdpale 6y ago

for the average person, all of those things you listed might as well be magic.