1436678 - Error when providing HTML5 audio with a base64 encoded Data URI as source

Status: UNCONFIRMED

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

Description

[Saurabh Verma]

Attachment: Firefox Audio base64 Data URI issue containing HTML, JavaScript files and related screenshots.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36

Steps to reproduce:

Firefox supports playing ogg files using HTML5 audio. So, I am trying to load HTML5 audio with a base64 encoded Data URI as the source. Consider the example given on website https://iandevlin.com/html5/data-uri/audio.php and check the audio metadata information.

I have attached my sample project and related screenshots zipped for reference. 

Note: Try to refresh many times if the issue is not repro. The attached file has an audio duration of 2 secs. This issue is very frequent for a large file.




Actual results:

Intermittently the metadata loaded by audio tag is wrong. Current time is not displayed in the audio control view. Also, the audio duration is displayed as 00:00 but while checking using JavaScript code it is infinity. When I click on play button the audio is directly seeking to end. In short, audio plays but all the other metadata is wrong.


Expected results:

Audio base64 encoded Data URI should have loaded correctly. Audio metadata should display information correctly. Also, audio should play fine.

Comment 1

[Ralph Giles (:rillian)]

I wasn't able to reproduce on Firefox 58 (release) for Firefox 60 (nightly). About 1 time in 10 when I shift-reload, no duration is displayed on the media controls until I click 'play' and playback completes, but playback always works I don't see the console warnings.

Are you sure the document is loading completely before you try playing?

Comment 2

[Saurabh Verma]

When the duration is not displayed in that case when the play is clicked the audio is sought automatically to end and it keeps on playing which is a buggy behavior. Also, in that case, as the duration is not present or invalid then we can't use duration for any of our purpose (e.g. suppose creating a custom media player where I want to fetch audio duration property and display it).

Observer below JSFiddle which I have created to repro the issue:

1. https://jsfiddle.net/sau752/5Lbb3801/
2. https://jsfiddle.net/sau752/n62qxu1s/2/

Note: As audio data is pretty large for above two fiddles, the page might take some time to load. I am using Firefox version 58.0.2 on Windows 10 64 bit machine.

Comment 3

[Saurabh Verma]

Yes, the document correctly loads before I try to play. Test above provided JSFiddle, you might be able to repro the same behavior as I have described. How can I use duration after loadedmetadata event is fired and duration is not present in that case?

Comment 4

[Saurabh Verma]

(In reply to Ralph Giles (:rillian) | needinfo me from comment #1)
> I wasn't able to reproduce on Firefox 58 (release) for Firefox 60 (nightly).
> About 1 time in 10 when I shift-reload, no duration is displayed on the
> media controls until I click 'play' and playback completes, but playback
> always works I don't see the console warnings.
> 
> Are you sure the document is loading completely before you try playing?

Can you please check the above-mentioned scenario and see if you are able to repro the same.

Comment 5

[Ralph Giles (:rillian)]

It's easier to see the issue with the longer example, thanks. In one case I got duration: infinity, but something just over a second for audioPlayer.seekable.end(0). It's definitely a bug, but data urls are something of an edge case and we may not be able to develop a fix quickly. You might want to explore other solutions.

Comment 6

[jackgao]

I was able to reproduce this issue when using large Base64-encoded audio Data URIs in Firefox 58 and later.
It seems that when the Base64 string exceeds a certain length, the decoding or memory handling within the audio playback pipeline causes partial or failed decoding.

To confirm this, I ran several tests by generating audio files and encoding them into Base64 strings of different sizes.
The smaller files (<1 MB) work fine, but anything larger can trigger inconsistent playback or "corrupt source" errors.

For anyone trying to debug or reproduce this behavior, you can easily create and test Base64 Data URIs online here:
👉 https://www.base64converter.online

This tool lets you encode/decode Base64 audio or image files directly in the browser, which helps isolate whether the problem comes from the data URI itself or the browser’s decoding logic.

Based on my tests, the issue is not with the Base64 encoding itself but rather with how Firefox allocates memory when decoding large inline audio streams.