Closed Bug 1362358 Opened 7 years ago Closed 7 years ago

Audio Mime Type detection differs on M4A-files depending on call by Javascript audio object or direct link

Categories

(Core :: Audio/Video, defect)

53 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: davidchristmann, Unassigned)

Details

Attachments

(3 files)

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

Steps to reproduce:

I am having trouble to play m4a audio files correctly. I set up a test page to show the issue and the steps to reproduce it:

http://123-bb.de/tests/audiotest/index.html



Actual results:

I have 2 different m4a files tested. One where the server sent the mime type "audio/mp4" and one where the mime type was "audio/mpeg".

For the "audio/mp4" file the sound was played correctly when called directly without a javascript audio object.
But when called from a javascript audio object ist wasn' played because Firefox detected the mime type "audio/3gpp" which ist not supported.

For the second file with mime type "audio/mpeg" it was the opposite. It was only played from within a javascript audio object where Firefox detected the mime type "audio/mp4" although the file was send as "audio/mpeg". A direct call without javascript object was not played due to wrong mime type "audio/mpeg".


Expected results:

Firefox should detect the same mime type no matter if a m4a-file is called directly or via a Javascript audio object.
audio/mpeg is the mimetype for a mp3 audio file.

When you attempt to play the file via src attribute however, what the server provides as mimetype is important.
Alternatively, the type attribute could be set to specify which mimetype to use.

https://www.w3.org/TR/html5/embedded-content-0.html#the-audio-element

Attempting to play a mp4 file when your server tells us that it's a MP3 will lead to a decoding error. It prevents attempting to download something we wouldn't otherwise be able to play.
If the file is in the cache however, there's no need to download.

You can't just ignore what the server mimetype is returning, if we always had to ignore that information, it would seriously hindered the speed at which you can render file.

But agree, something isn't quite right here
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
(In reply to David from comment #2)
> Created attachment 8864831 [details]
> Shows the wrong mime type Firefox sets when using Javascript Audio Object

This is what your m4a file set it is made of:

[ftyp] size=8+16
  major_brand = 3gp4
  minor_version = 0
  compatible_brand = isom
  compatible_brand = 3gp4

the file says it's a 3gp4 file. We don't play those file...

hence why sniffing fail.
But why is it played when you call the file directly? (like in step 4 or step 6 in the first example)
Shows mime type is ok when m4a file is called directly in Firefox
My explanation in the earlier comment was invalid (it's the wrong way around).

It's all to do with how the DOM object is constructed. In one case, you can tell what the mimetype is at construction time (by checking the mimetype), in the other you can't without sniffing the file.

When you attempt to load the file directly, it uses the Content-Type header from your server which is "Content-Type: audio/mp4" when constructing the DOM. As such, it creates an audio element whose type is set to "audio/mp4".

The file is placed in the Media Cache, and with that audio/mp4 mimetype. When you access it again, there's no longer a need for sniffing. it knows what it is.

When you loaded the file in JS, the DOM has been constructed, it will then use sniffing on that URL. Sniffing is done by only looking at the ftyp box. That box in this case indicates the wrong type.

Chrome and IE works in a similar fashion, however they supports 3gp4 file natively so you can't notice a difference in behaviour.

I had raised that issue a few years back.. When I find the bug, I'll attached it here. It contains further details about how DOM objects are constructed.
Ok, Thank you very much for your answer. Now I can understand the behaviour.

Shows mimetype and Content-Type mismatch

Attachment #9057402 - Attachment description: Firefox audio bug.png → Shows mimetype and Content-Type mismatch
Comment on attachment 9057402 [details]
Shows mimetype and Content-Type mismatch

I don't understand all this but I'm not sure I understand why this issue was closed.  Is this not indeed a bug?

I also don't understand why the Content-Type response header is not consulted if the audio element is loaded via JS since it still needs to connect to the server and should be able to use the Content-Type as shown in this screenshot.

If this is not a bug, can you explain why not and whether there is a workaround?

The problem exists with both Firefox 66.0.3 on Mac and 66.0.1 on Linux Mint.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: