(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: [ftyp] size=8+16 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: see https://jyavenard.github.io/htmltests/tests/1552194/1552194.html > 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". The type audio/mpeg is wrong though, that tells that it's MP3. audio/mp4 is the proper mimetype as your file is aac > Firefox should detect the same mime type no matter if a m4a-file is called directly or via a Javascript audio object. 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. What's interesting however, is that this page hosted on a local apache2 server doesn't exhibit any of those behaviours. I'll do some experimentations on what happens if we accept 3gp4 in a ftyp
Bug 1552194 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(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: [ftyp] size=8+16 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: see https://jyavenard.github.io/htmltests/tests/1552194/1552194.html 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. > 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". The type audio/mpeg is wrong though, that tells that it's MP3. audio/mp4 is the proper mimetype as your file is aac > Firefox should detect the same mime type no matter if a m4a-file is called directly or via a Javascript audio object. 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