You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you try to load an mp4 file which only contains audio using an http https or file url, howler.js handles this without any issue, however if you try to load that same exact mp4 file, by loading it into memory first and converting it to a data uri, howler.js complains "No file extension was found." and doesn't load the file.
Reproducible Example
No response
Reproduction Steps
Using an audio-only mp4 file, try creating a new howl instance using the url to that file. The audio will load after some time.
Using that same file, load the binary data into memory (via xhr or in my use case, using adm-zip) and convert it into a data uri ensuring you set the mime-type to be the same (eg. video/mp4) as in the first network request. The audio will not load, will remain in the "unloaded" state, and will throw a warning that "No file extension was found."
Possible Solution
Instead of checking for audio/* in the regex for attempting to discover the "extension", either check for (audio|video) or check for */*
Context
This might be a niche context, but I work on a project which simulates a mechanical keyboard by playing audio on keypresses, and am trying to make "importing" sound packs easier, by not needing to extract zip archives. However, in order to achieve that the sound files are loaded into memory, and provided to howler.js via data uri's, which work for the most part, but people are weird, and there are a surprisingly high number of sound packs which were created using audio-only mp4 files for some reason.
For backwards compatibility sake, I have to make these packs work with this new feature, but due to this bug in howler, I have to intercept the mime-type and replace video with audio, instead of easily being able to just pass the mime-type directly to howler as-is.
Howler.js Version
v2.2.4
Affected Browser(s)/Versiuon(s)
No response
The text was updated successfully, but these errors were encountered:
The Problem
If you try to load an mp4 file which only contains audio using an http https or file url, howler.js handles this without any issue, however if you try to load that same exact mp4 file, by loading it into memory first and converting it to a data uri, howler.js complains "No file extension was found." and doesn't load the file.
Reproducible Example
No response
Reproduction Steps
Using an audio-only mp4 file, try creating a new howl instance using the url to that file. The audio will load after some time.
Using that same file, load the binary data into memory (via xhr or in my use case, using adm-zip) and convert it into a data uri ensuring you set the mime-type to be the same (eg. video/mp4) as in the first network request. The audio will not load, will remain in the "unloaded" state, and will throw a warning that "No file extension was found."
Possible Solution
Instead of checking for audio/* in the regex for attempting to discover the "extension", either check for (audio|video) or check for */*
Context
This might be a niche context, but I work on a project which simulates a mechanical keyboard by playing audio on keypresses, and am trying to make "importing" sound packs easier, by not needing to extract zip archives. However, in order to achieve that the sound files are loaded into memory, and provided to howler.js via data uri's, which work for the most part, but people are weird, and there are a surprisingly high number of sound packs which were created using audio-only mp4 files for some reason.
For backwards compatibility sake, I have to make these packs work with this new feature, but due to this bug in howler, I have to intercept the mime-type and replace video with audio, instead of easily being able to just pass the mime-type directly to howler as-is.
Howler.js Version
v2.2.4
Affected Browser(s)/Versiuon(s)
No response
The text was updated successfully, but these errors were encountered: