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

Firefox fails to fire progress event without preload attribute #150

Open
bekriebel opened this issue Apr 2, 2020 · 3 comments
Open

Firefox fails to fire progress event without preload attribute #150

bekriebel opened this issue Apr 2, 2020 · 3 comments

Comments

@bekriebel
Copy link

For some video files (seems to primarily happen on MPEG 4 Type 2 files), the Progress event does not fire for a loaded resource on Firefox 74. This seems to be caused when not enough of the partial content range has been loaded by the browser's default preload value on a media element.

Since the loader should be requesting that the resource be loaded fully, the preload attribute should be set to auto.

For the 3.x branch, I tested this by adding this.data.preload = 'auto'; right before this.data.load(); here: https://github.com/englercj/resource-loader/blob/release/3.x/src/Resource.js#L636. However, this should probably be wrapped in an if statement to only add preload to a video type element.

You can see that a video is not being preloaded with any video file by watching the network traffic and seeing that only the first bits of the file are downloaded. This doesn't seem to cause the progress event failure for all videos, though. I can link to a video that causes the progress issue reliably in a private message, or I can try to find or create a free video that causes the issue if needed.

@englercj
Copy link
Owner

englercj commented Apr 4, 2020

In v4 you can make changes to VideoLoadStrategy to support this. However, not every video should set this property because not every video should load the entire video.

Since the loader should be requesting that the resource be loaded fully

Not strictly true, we actually wait until canplaythrough is true which can happen way before the entire video is loaded. That is by design. Setting preload auto sounds like a good feature, but it should be an option.

@bekriebel
Copy link
Author

The problem I am seeing is that with Firefox 74, unless autoplay is set to true or preload is set to auto. canplaythrough is never reached for some videos. When I compared Firefox and Chrome, it appears that Chrome also handles loading differently depending on preload being blank or auto.

preload = ''
Firefox: Loads a small amount of the file (I assume metadata only). For some files, this is enough for the Progress event to fire, for others it is not.
Chrome: Loads a small amount, but more of the file. I haven't seen the Progress event not be hit with the amount of data that is loaded.

preload = 'auto'
Firefox: Begins loading the entire video. The Progress event fires reliably here, I assume when canplaythrough is reached.
Chrome: Still only partially loads the file, but significantly more than when preload was blank. It looks like it loads enough for smooth playback of the file based on bandwidth.

To me, auto is the preferred outcome in the case for when load is being called. However, it can certainly be an option as well. As a workaround, I'm creating my own loaderElement and setting the preload. Maybe that will be easier done with 4.x. I'm also using it through Pixi.js at the moment, and there might be something I can add downstream in that project as well.

@englercj
Copy link
Owner

englercj commented Apr 7, 2020

Reading through the load() and preload docs again cleared it up for me. I think it is probably a good idea to set this to 'auto' in the video load strategy.

Might need to add a hook in the media strategy for the video class to set this. Like a protected _prepareElement() function, for example.

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

2 participants