Streaming via rtmp/OBS

[lovelaced]

Hi all,

I've been working on getting this deployed and set up properly for around the past week; have been keeping up to date with all the new commits :) very excited to see where this goes! Awesome stuff so far. So far I have everything working including pretalx integration (very slick!) and can stream via the rtmp nginx module to hls just fine, no hiccups in stream at all, like this:

ffmpeg -re -i /tmp/media.mp4 -vf-c:v libx264 -preset veryfast -b:v 3000k -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p -g 50 -c:a aac -b:a 160k -ac 2 -ar 44100 -f flv rtmp://localhost/hls/stream

However, when attempting to replicate this with OBS (via rtmp, again) (note: I am no expert in OBS), for some reason it doesn't really work. There's a lot of lag, and the browser console complains about not being able to load partial chunks (but this works just fine when the endpoint is streamed to with ffmpeg). I'm wondering if there are any venueless-specific issues here - what kind of preflight requests does the player actually expect? Is there a way to debug this? What's the best method to stream to venueless?

Sorry if this question is out-of-scope, but a lot of smaller examples of simple web players + nginx-rtmp configuration I've read don't seem to have this issue.

[rashfael]

We switched from shaka-player to hls.js just today, because we are seeing better stability with hls.js. hls.js has a demo page with a lot of debug info rendered, perhaps you have some luck finding something there: https://hls-js.netlify.app/demo/

[lovelaced]

Thanks, this seems to work somewhat better. ffmpeg still works fine, but unfortunately streaming with OBS does not; it works with some lag (I understand that's normal, I'm using twitch as a benchmark here, and this is a server-side problem on my part). I get a couple of error messages and interruptions when streaming (which I do not see when streaming the same endpoint with mpv). Tried in both Firefox and Chrome.

Use of Mutation Events is deprecated. Use MutationObserver instead.

Media resource blob:https://<fqdn>/ce605296-d169-4520-af98-02824d4438aa could not be decoded.

After a long stall in-browser I got this error in FF: Media resource blob:https://<fqdn>/ce605296-d169-4520-af98-02824d4438aa could not be decoded, error: Error Code: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) Details: RefPtr<MediaSourceTrackDemuxer::SeekPromise> mozilla::MediaSourceTrackDemuxer::DoSeek(const mozilla::media::TimeUnit &): manager is detached.

[rashfael]

The decoding errors are probably coming from the browser itself. (How) are you transcoding your stream? We found that, when using nginx-rtmp, always transcoding is more stable.

[lovelaced]

Thanks for the tip. I ended up increasing playlist length to 30s and it seems to have helped considerably. A friend of mine guessed that mpv just uses much more aggressive buffering. I'll close this for now since it seems to be working pretty well, besides some strange visual effects when the stream stops (intermittent flickering between the final frame of the stream and the grey "Stream Offline" page).

For the record these settings seem to work for me for anyone wondering about this in the future:

    events {}
    http {
        sendfile off;
        tcp_nopush on;
        directio 512;
        fastcgi_buffers 16 16k; 
        fastcgi_buffer_size 32k;
        default_type application/octet-stream;
    }
    rtmp {
        server {
            listen 1935;
            listen [::]:1935 ipv6only=on;    
            chunk_size 4096;
            application hls {
                live on;
                hls on;
                hls_path /tmp/hls/live;
                hls_playlist_length 30s;
                hls_fragment 1s;
                deny play all;
            }
        }
    }