Handle network issues in video player

[kontrollanten]

Description

Handle network issues in video player.

• Offline handling
• Fallback to other resolution upon network error
• Display user friendly interface upon unresolved error

Related issues

closes #4782

Has this been tested?

• 🙅 no, because this PR does not update server code

Screenshots

[emansom]

I would be very grateful if you added some logic to this PR to make the video player silenty retry on HTTP status code 429 (Too Many Requests).

Taking the amount of seconds to wait for before a retry is attempted from the response header Retry-After, if available.

[kontrollanten]

I would be very grateful if you added some logic to this PR to make the video player silenty retry on HTTP status code 429 (Too Many Requests).

Taking the amount of seconds to wait for before a retry is attempted from the response header Retry-After, if available.

It seems that the status code is provided in the errorData object, so it shouldn't be hard to fix. I'll look into that.

[kontrollanten]

It seems that the status code isn't in the actual error object, it seems like a hls.js bug. video-dev/hls.js#4852

After thinking a bit that may be a separate issue since a 429 response will probably affect the user, and I think they be informed that it isn't working as expected. Do you have a proxy that respond 429 or why are you experiencing that? It doesn't seem that PeerTube are having any rate limit on the static files.

[emansom]

It seems that the status code isn't in the actual error object, it seems like a hls.js bug. video-dev/hls.js#4852

After thinking a bit that may be a separate issue since a 429 response will probably affect the user, and I think they be informed that it isn't working as expected. Do you have a proxy that respond 429 or why are you experiencing that? It doesn't seem that PeerTube are having any rate limit on the static files.

Thanks for looking into it! 👍🏻

HTTP Status Code 429 is intended as a form of rate limiting. It tells clients to retry automatically after a cool off period, adhering to the Retry-After instructions sent by the server.

I've configured my own PeerTube instance to send the 429 status code when requests per second on video fragments exceed a certain amount, nullifying attempts to leech bandwidth by malicious user agents.

An adjustment I made to the NGINX configuration after discovering a malicious client was DoSing by requesting fragments from various IP addresses at once.

It can sometimes be triggered by skipping segments really fast as well, which leads to a bad user experience; crashing the player.

Made the following adjustments to the NGINX configuration. Will upstream this once I settled on the best request rate. Lower it (and/or remove burst) to trigger the 429:

Within the http { } block inside nginx.conf place:

  limit_conn_zone $binary_remote_addr zone=peertube_video_ip:10m;
  limit_conn_zone $server_name zone=peertube_video_total_conn:10m;

  # decrease rate below to trigger 429
  limit_req_zone $binary_remote_addr zone=peertube_video:10m rate=3r/s;

  limit_req_status 429;
  limit_conn_status 429;

Within the server { } block ensure the video fragments location { } block inside /etc/nginx/conf.d/domain.tld.conf contains this:

    location ~ ^/static/(webseed|redundancy|streaming-playlists)/ {
        limit_conn peertube_video_total_conn 10000;
        limit_conn peertube_video_ip 10;

        # adjust or delete burst and delay to trigger 429 sooner
        limit_req zone=peertube_video burst=4 delay=2;

        limit_rate_after 5M;
        set $peertube_limit_rate 800k;

        if ($request_uri ~ -fragmented.mp4$) {
            set $peertube_limit_rate 5M;
        }
        limit_rate $peertube_limit_rate;

[Chocobozzz]

Hi,

Can you explain why a specific resolution could be broken?

[kontrollanten]

#5110 and #3407 for example. It's way optimistic to think that it will never happen again.

[emansom]

Another usecase could be for example when watching using a spotty 4G LTE connection.

[kontrollanten]

Another usecase could be for example when watching using a spotty 4G LTE connection.

But in that case I assume we don't want to remove the resolution from the player (which is done in this PR)? In case of a spotty connection it will retry for some times, and then go to another resolution.

[Chocobozzz]

Thanks!