Closed Bug 1757387 Opened 4 years ago Closed 8 months ago

Cannot use a Data URL as a source for an <audio> tag for large files

Categories

(Core :: Audio/Video: Playback, defect, P3)

Product:
Core
Component:
Audio/Video: Playback
Version:
Firefox 97
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
136 Branch
Tracking Flags:
Tracking Status
firefox-esr91 --- unaffected
firefox-esr115 --- wontfix
firefox-esr128 --- wontfix
firefox97 --- wontfix
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- wontfix
firefox134 --- wontfix
firefox135 --- wontfix
firefox136 --- fixed

People

(Reporter: florian.sw, Assigned: valentin)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [fixed by bug 1911300])

Attachments

(1 file)

index.html
898 bytes, text/html
Details
Attached file index.html —

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

I have this minimal Web Page source code (Also, see attachment):

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <input type="file" id="fileinput">
    <audio controls id="audio" >
    <script>
        const fileInput = document.getElementById('fileinput');
        const audio = document.getElementById('audio');

        fileInput.onchange = function(e){
            console.log(e.target.files)
            const fileReader = new FileReader()
            fileReader.onload = () => {
                audio.src = fileReader.result;
            }
            fileReader.onerror = console.error;
            fileReader.onabort = () => console.log("File Reader aborted!")
            fileReader.readAsDataURL(e.target.files[0])
        }
    </script>
</body>
</html>

A audio file (e.g. .wav, .flac, .mp3) is read by a <input type="file"> tag and converted to a Data URL by a FileReader.

In other words: The problem occurs when trying to set a "Data URL" as a src attribute of an HTML Audio tag. The same applies when using a separate <source> tag as the child of the audio tag.

Steps to reproduce:

  1. Open the HTML file according to the source code above (or see attachment)
  2. Upload an audio file, at least 30mb in size
  3. click the play icon of the audio player

Actual results:

The Audio Player displays 0:00 as audio length and no audio plays when starting the audio player.
In the console, this Warning is displayed: "Invalid URI. Load of media resource data:audio/flac;base64,Zkx........"

Expected results:

No warnings should be displayed in the console.
The audio player should display the actual length of the audio file and the audio file should be played.

The bug ocurred on:
Firefox 97.0 (64-bit)

This was tested and did not occur on:
Firefox for Linux Mint 95.0.1 (64-bit)
Chromium Version 98.0.4758.102 (Official Build) snap (64-bit)

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Managed to reproduce the issue on Windows 10 x64, macOS 11.6 and on Ubuntu 20.04 x64 on Firefox Nightly 99.0a1, Firefox 98.0-candidates build 1 and on Firefox 97.0.1.
On Firefox 91.7.0esr the issue is displayed different, for the first upload the length of the audio file is not accurate but if you repeat the upload the length will be displayed correctly.

Severity: -- → S3
Status: UNCONFIRMED → NEW
status-firefox97: --- → affected
status-firefox98: --- → affected
status-firefox99: --- → affected
status-firefox-esr91: --- → unaffected
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → Desktop
Blocks: media-triage

Feels like some sort of data scheme change. Asking around to see if we've made changes there.

No longer blocks: media-triage
Severity: S3 → S4
Regressed by: 1721448

Set release status flags based on info from the regressing bug 1721448

status-firefox100: --- → affected
status-firefox101: --- → affected

:valentin, since you are the author of the regressor, bug 1721448, could you take a look?
For more information, please visit auto_nag documentation.

Flags: needinfo?(valentin.gosu)

Bug 1721448 introduced a 32 Mb size limit for data URLs.
We could potentially increase this limit to around 100Mb if this turns out to cause major webcompat issues. If that's not enough then it'd require some significant redesign of the IPC/URL code. (Note, I'm not regularly reading bugmail. If this needs my attention please ping me on slack).

Flags: needinfo?(valentin.gosu)

Why not pass the audio via blob instead of data? That would require less memory than the duplication that ensues from the use of the data URI (the entirety of which needs to be inserted in the DOM when you assign to audio.src), and it doesn't require the browser to first read the entire file into memory, like the data URI approach. Something like:

// ...
fileInput.onchange = function(e) {
  const file = e.target.files[0];
  const url = URL.createObjectURL(file);
  audio.src = url;
}

should work, right? (live example: https://jsbin.com/tuzizekuxi/edit?html,js,output )

This would likely perform much better for large files anyway.

Flags: needinfo?(florian.sw)

Using blob instead of data may be a good solution for future applications. But the new 32 Mb limit breaks working applications (e.g. existing html files that have been in use for years, most of them for offline use), when still using Firefox. The only work-around for those cases would be to use Chrome or Edge where these files still work.
So, increasing the limit to 100 Mb would help in many cases. Embedding data larger than 100 megs has not made sense so far anyway cause it took too long to load the html file.

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(florian.sw)

(In reply to :Gijs (he/him) from comment #8)

Why not pass the audio via blob instead of data? That would require less memory than the duplication that ensues from the use of the data URI (the entirety of which needs to be inserted in the DOM when you assign to audio.src), and it doesn't require the browser to first read the entire file into memory, like the data URI approach. Something like:

// ...
fileInput.onchange = function(e) {
  const file = e.target.files[0];
  const url = URL.createObjectURL(file);
  audio.src = url;
}

should work, right? (live example: https://jsbin.com/tuzizekuxi/edit?html,js,output )

This would likely perform much better for large files anyway.

I solved this problem in some other way. I would agree that it would make sense to have the limit at 100mb to not break existing applications. I am processing wave audio files, so it was fine most of the time, but of course those files could sometimes be bigger so that's why i changed it. Data URL is only for small data but it wasn't obvious to me until i encountered the bug.

This is not WFM since bug 1911300, which increased the limit to 512MB.

Depends on: 1911300

(In reply to Mayank Bansal from comment #12)

This is not WFM since bug 1911300, which increased the limit to 512MB.

Are you saying this now works, because we've increased the limit? (meaning typo now/not?) Or something else?

Flags: needinfo?(mayankleoboy1)

typo. always a typo.
Rephrasing: This testcase works for me now.
Profile of playing a 300mb mp4 file: https://share.firefox.dev/3CyWb0X

Flags: needinfo?(mayankleoboy1)

Closing per last few comments.

Assignee: nobody → valentin.gosu
Status: NEW → RESOLVED
Closed: 8 months ago
status-firefox134: --- → wontfix
status-firefox135: --- → wontfix
status-firefox136: --- → fixed
Resolution: --- → FIXED
Whiteboard: [fixed by bug 1911300]
Target Milestone: --- → 136 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: