(In reply to Marco Moreno from comment #0)
Apologies if cloning this bug is inappropriate, but I could not figure out how to reopen the original bug report. As I mentioned in a comment on the original bug, I don't understand why this issue was closed. Is this not indeed a bug?
The attached screenshot shows how a mismatch between the audio's incorrect mimetype and the Content-Type from its response header. Why is the Content-Type not used? Even if the audio element is loaded via JS, it still needs to connect to the server and should be able to use the Content-Type that is provided. There should be no need to resort to sniffing the file. And even if all efforts fail, it certainly should not simply default to the first mimetype in a list (which is what it appears to do by assigning '3gpp').
Content-Type must be ignored per spec. I mentioned this in comment 6.
There was a long discussion between the various user-agent maker (Microsoft, Google, Apple, Mozilla) and they came to the conclusion that the content type of a file must always be determined via sniffing.
As described in bug 1362358 comment 6; that 10.m4a file binary looks like this:
major_brand = 3gp4
minor_version = 0
compatible_brand = isom
compatible_brand = 3gp4
This tells us that the file type is 3gp4 which we can't play. This is why step 3 gives you nothing.
If this is not a bug, can you explain why not and whether there is a workaround?
the work around is to remux your file so that they have the proper binary format.
Something like this will do:
ffmpeg -i 10.m4a -c:a copy -c:v copy 10-new.m4a
Your file will now always play as you expect:
The original file in the page above is named: 10-3gpp.m4a
you can test with 10.mp4 and 10.m4a which are the remuxed file.
The type audio/mpeg is wrong though, that tells that it's MP3. audio/mp4 is the proper mimetype as your file is aac
For you to get consistent result regardless of how the file is loaded, it must be valid.
Now we could add 3gp4 as supported mimetype, however typically a 3gp4 file is not aac, it's AMR which we do not support. But you would get a decoding error there instead.
At a guess when the file is in the cache, as it's been played before the resource type got stored too and filled with the right value and not the incorrect one.
I'll do some experimentations on what happens if we accept 3gp4 in a ftyp