Repository navigation
fix: don't undo Video.js source fallback on media error - #1093
Merged
Merged
Conversation
✅ Deploy Preview for cld-video-player ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for cld-vp-esm-pages ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Video.js retries the next source on error before playback. handleCldError ran on the same error and reloaded the full source list, putting the failed source (e.g. hls/h265 on browsers without HEVC) back first and ending in error 6. Only recover when Video.js didn't clear the error.
tsi
force-pushed
the
fix/hevc-h264-fallback
branch
from
October 1, 2026 08:45
1cc746c to
f8d8783
Compare
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
With
sourceTypes: ['hls/h265', 'hls/h264'], browsers that cannot decode HEVC (Windows Edge/Firefox without GPU HEVC support) ended in error 6 "No supported media sources" instead of playing the h264 fallback. Video.js already retries the next source when one fails before playback; ourhandleCldErrorran on the sameerrorevent, reloaded the full source list with h265 first, and undid that fallback.The regression was introduced in #880, which started calling
player.error({ code: 4 })for every fatal hls.js error. Before that, the fatal error only fired anerrorevent without setting a player error, sohandleCldErrornever ran and the Video.js retry handled the fallback alone (this is why v2.1.1 works and v4.1.2 does not).Changes
handleCldErrorby one tick and only run it if Video.js did not already clear the error. Video.js's retry clears it synchronously inside the sameerrordispatch, so when it fires we skip our recovery and let the next source load. When nothing is left to retry (single source, or all sources failed), the error is still set after the tick andhandleCldErrorruns exactly as before.test/unit/source-fallback.test.jscovering both branches of the deferred check.Related
videoSourcesTypeError:fix/hevc-h264-fallback-reproHow to Test
Manual check on a browser without HEVC decoding (Windows Edge/Firefox), or on any browser by stubbing
MediaSource.isTypeSupportedto returnfalseforhvc1/hev1before the player loads (the stacked follow-up branch has a page that does this via?simulateNoHevc=true):sourceTypes: ['hls/h265', 'hls/h264']withsourceTransformation{ 'hls/h265': [{ streaming_profile: 'full_hd_h265' }], 'hls/h264': [{ streaming_profile: 'full_hd' }] }, public IDdogon thedemocloud.manifestIncompatibleCodecsError), h264 loads and plays,player.videojs.error()stays null, noTypeError ... reading 'videoSources'in the console.['hls/h264']only, and a run on a browser with HEVC support, play as before.The error display that #880 added is preserved. With
sourceTypes: ['hls']and a transformation thatsp_autorejects (for example{ aspect_ratio: '9:16', crop: 'fill' }), the manifest request returns 400 and the player still shows "Video cannot be played- sp_auto transformation is not allowed (aspect_ratio is not supported)" withstatusCode: 400, identical to v4.1.2.Notes
playing, which is the window where Video.js's retry is still armed, so the same path applies. Please confirm on BrowserStack before release.videoSourcesTypeError no longer occurs with this fix, since it was caused by the mid-load source swap. A defensivesource?.guard in thecldsourcechangedlistener is in the stacked follow-up branch rather than here.handleCldErrorstill retries the failed h265 first. Follow-up: skip the source that just failed.