CODE:3 MEDIA_ERR_DECODE should not break the player

[pedromcunha]

Description:

If you load a playlist that throws the MEDIA_ERR_DECODE the player breaks and has to be completely recreated to resume the video. Here is an example: fiddle

Expected:

It should be expected that the player would encounter the error, take note of it and then skip forward. Notice that if you skip past the segment it actually continues to play (because it doesn't encounter the issue). I do feel like some users of this library would want to see the error and handle it their way. So I propose that we give developers the ability to rescue the player from crashing.

[dmlap]

When a decode error is hit, the source buffers, media source, and video element are put into an unrecoverable state. To handle this situation, we'd have to unload the media source which would throw out all existing buffering. After creating a new media source and attaching it, the choices I see are:

1. Seek forward immediately past the broken segment. Under normal operation we're buffering 30 seconds ahead of currentTime so this will probably result in the viewer missing 40 seconds of content.
2. Rebuffer content at currentTime up to the broken segment, wait for playback to stall at the gap, and then skip over it.
3. If there's a variant playlist available, blacklist the current playlist, rebuffer everything, and hope that the decode error doesn't occur in the variant.

In 1. and 2., there's still a question of what to do if the viewer seeks back to the broken segment. In any of the cases, the viewer is definitely going to notice something bad is happening and I don't think the experience will be better than destroying and recreating the player.

All of the options are quite complicated and seem like they would result in a bad user experience (without better platform support, at least). Based on that, I think the best option is to fix whatever issues are causing the DECODE errors in the first place. I'm going to close this one based on that analysis but if anyone has an alternate implementation idea that has better behavior than my proposals above, please continue commenting!

[pedromcunha]

I agree with your analysis and have implemented something similar to this. Basically I keep in memory a hashmap of where the decode error happened and then reload the player. I then go one segment past the affected segment. Whenever the video loops or the user seek, I check to see if the seeked to time is in the affected range and push it forward past the range.

I also added a fallback in case a video gets stuck download the same segment for eternity (it's a weird bug that's been posted around in this repo). I hope to have a micro library that will hopefully patch these issues for the time being. I agree that the platform support would make this micro library obsolete but for now it's the best we can do.

[dmlap]

@pedromcunha any chance you could share your micro-library? Sounds like some of the folks on this issue would be very interested.