Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend hlsjsConfig with ability to ignore errors #102

Open
stevendesu opened this issue Sep 10, 2019 · 1 comment
Open

Extend hlsjsConfig with ability to ignore errors #102

stevendesu opened this issue Sep 10, 2019 · 1 comment

Comments

@stevendesu
Copy link

Currently when a fatal error is thrown and cannot be recovered, _hls.destroy() is called, tech.error is set, and the error event is triggered. This basically halts all playback, forces an error display on the player, and makes recovery nearly impossible.

In some cases people may want to implement their own recovery logic - particularly if they have unique insights into the reason for the failure, or a special fallback case. In my case, a stream had two different M3U8 URLs. When one failed to play, the other could be used as a backup (different cameras for the same event). I therefore wishes to intercept the HLS error event and, if fatal, switch to the other camera, seek to the same currentTime(), and continue playback.

It would be nice if the entire _onError method were optional, perhaps with something like:

    var options = {
        html5: {
            hlsjsConfig: {
                ignoreErrors: true
            }
        }
    };
@stevendesu
Copy link
Author

In particular, I would even like to prevent videojs-hlsjs-plugin from calling _hls.recoverMediaError(), as this unloads and reloads the video, putting a play button in front of the user - which is rather confusing during a live stream (and arguably confusing even during VOD without any messaging to explain why their video just started over)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant