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

Blob Url Support broke with 7.2.1 #5504

Closed
flipace opened this issue Oct 13, 2018 · 7 comments · May be fixed by CleverTap/vue-video-player#3
Closed

Blob Url Support broke with 7.2.1 #5504

flipace opened this issue Oct 13, 2018 · 7 comments · May be fixed by CleverTap/vue-video-player#3

Comments

@flipace
Copy link

flipace commented Oct 13, 2018

Description

When using a dynamically generated blob url as a video source, any player interaction will be silenced by video.js

It works flawlessly when triggering .play() directly on the HTMLVideoElement though.

Reproduction case with comparison of 7.2.0 and 7.2.1: https://github.com/flipace/video.js-7.2.1-blob-issue. This is related to a change made in #5371

Steps to reproduce

  1. Generate a blob url for a video
  2. Pass the blob url as a src (with type) to videojs
  3. Try triggering playback of the video

Results

Expected

Playback should start when clicking the play button(s).

Actual

Nothing happens.

Error output

No errors. video.js is stuck and will always wait for the video to be loaded into its internal source cache (which never happens though)

Additional Information

versions

videojs

7.2.1 and above are affected

browsers | OSes

since this is a videojs internal issue probably all of them

@welcome
Copy link

welcome bot commented Oct 13, 2018

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.

gkatsev pushed a commit that referenced this issue Oct 25, 2018
Instead of checking for blob urls in the generic updateSourceCaches method, check for blob urls inside of handleTechSourceset before updating the source cache.

Fixes #5504.
@gkatsev
Copy link
Member

gkatsev commented Oct 25, 2018

Just merged a fix, we should be making a release tomorrow.

@flipace
Copy link
Author

flipace commented Oct 26, 2018

awesome! thanks @gkatsev and @brandonocasey !

@andygale
Copy link

Thank you. I was waiting for this fix :)

@gkatsev
Copy link
Member

gkatsev commented Oct 26, 2018

It's out in 7.3.0, please try it out and report back if there are problems. If necessary, we can make a 7.2 patch but hopefully it won't be :)

gkatsev pushed a commit that referenced this issue Oct 31, 2018
Instead of checking for blob urls in the generic updateSourceCaches method, check for blob urls inside of handleTechSourceset before updating the source cache.

Fixes #5504.
@maxpaj
Copy link

maxpaj commented Apr 9, 2019

Using [email protected], I just tried using a blob:// source URL, like this:

player.src("blob://...");

It doesn't work. HTML5 tech says it can't play it. However, if you specify a source object like this, with a type, it works:

player.src({ src: "blob://...", type: "video/webm" });

I suspect it's due to:

  1. Sources supplied as strings are reconstructed as a source object with Util.filterSource, which tries to find the mime type using Util.getMimeType
  2. Url.getFileExtension won't return anything since the blob URL ends with no file extension
  3. Html5.nativeSourceHandler.canHandleSource determines whether it can play the source from the mime type

It's totally fine to supply the type for the source object, but with no good error being produced when you don't provide it, it can be quite confusing.

Suggestion: Perhaps add some check where it fits if the mimetype of the source cannot be determined.

@brandonocasey
Copy link
Contributor

Interesting, you may want to open this as a new issue

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants