rtsp-simple-server VS hls.js

If you want to stream your webcam as an H264 encoded rtsp stream, it can be done with either rtsp-simple-server or V4l2rtspserver And it is possible to stream a linux desktop (and any program that might be open, like your web browser with the gcode viewer running on it) with the V4l2Loopback device and either of the two prgrams above. It is quite an involved process, but it is do-able.

rtsp-simple-server

Download rtsp-simple-server_v0.20.2_linux_arm64v8.tar.gz from https://github.com/aler9/rtsp-simple-server/releases/download/v0.20.2/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 9379k 100 9379k 0 0 3497k 0 0:00:02 0:00:02 --:--:-- 6115k Finished. make[1]: Leaving directory '/home/pi/crowsnest/bin' Add User pi to group 'video' ... [OK] chown: invalid group: ‘pi:pi’e ... make: *** [Makefile:37: install] Error 1

I've tried using ffmpeg and rtsp simple server:

Ok, you need a NAS or their Cloud, a simple USB drive won't do it. The important thing is you need the receiving device to offer a transfer protocol named 'RTSP'. Modern Synology, QNAP, and MyCloud (by WD) devices support RTSP, although different methods to connect. Eufy Cloud would be the easiest method, next is Synology NAS is simple to setup with Eufy instruction, but since you have some hardware you can run things like this: https://github.com/aler9/rtsp-simple-server but obviously that will take more time and effort.

Very cool - going to try this out later. I had something similar on my todo list, but figured I would use: https://github.com/aler9/rtsp-simple-server

I had a nightmare setting this up for my streams. I ended up going with rtsp-simple-server as it seems to work a little quicker and is much better documented. There is an option to toggle between always having a stream "live" or stop when there are no viewers

Here is one example that I found (there are more). https://github.com/aler9/rtsp-simple-server

Good point; there's only a single server handling all the requests so things can be a bit slow depending on the time of day. And there are browser limits to the number of concurrent connections.

Apple browsers with native HLS support are better than those without as well. Other browsers need to load everything via https://github.com/video-dev/hls.js/ which slows things down.

Another user using Ubuntu + Firefox just reported this issue recently. You're likely running into this issue - the streaming library we use requires a codec that some browsers have bundled, but Firefox is not one of them. It expects the OS to provide it, and it sounds like yours is not.

I'm trying to build a simple web player for Jellyfin, for another project I'm working on that will embed a clipper. I am using HLS.js to load HLS streams, which seems to work really well for movies, but not at all for shows.

If you mean hls.js https://github.com/video-dev/hls.js/, I prefer Shaka because it can play both HLS and DASH, adding tons of stuff on top of it

I don't know the answer to the WebRTC part, but as long as you have a server with not-outrageously-priced outbound bandwidth, you can install an open source RTMP server like SRS[1], and stream to that RTMP server from OBS. It's really easy, configure the RTMP server & stream key, then "Start Streaming" which is right next to "Start Recording". You can then hand your friends a link, and they can play it in any media player with RTMP/HLS/FLV stream support, or you can add a simple web UI with e.g. hls.js[2] (very easy to write, there might even be prepackaged solutions) so that they truly don't need to download anything.

[1] https://github.com/ossrs/srs

[2] https://github.com/video-dev/hls.js/

I think HLS.js solved the same issue for H264.

hls.js

https://github.com/video-dev/hls.js/ <--download the release.zip, unpack it, extract dist/hls.js and dist/hls.js.map you can discard the rest. Near as I can tell these do not contain any external HTTP calls, IE: it's fully self-contained.