搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

Learn More

Can't play <audio> from website; but can from local file

  • 5 个回答
  • 47 人有此问题
  • 27 次查看
  • 最后回复者为 Epicanis

more options

I have the following HTML up at my website: <audio src="gnoss.ogg" controls autoplay> <bgsound src="gnoss.mid"> </audio> When I load the website from my webserver into Firefox, a blank control box shows up and nothing plays. When I load the very same site from my local disk into Firefox, everything functions perfectly. The website also functions perfectly in Chrome, both from the webserver and from my local disk.

I have the following HTML up at my website: <audio src="gnoss.ogg" controls autoplay> <bgsound src="gnoss.mid"> </audio> When I load the website from my webserver into Firefox, a blank control box shows up and nothing plays. When I load the very same site from my local disk into Firefox, everything functions perfectly. The website also functions perfectly in Chrome, both from the webserver and from my local disk.

所有回复 (5)

more options

The file http://www.mindspring.com/~giammo/personal/gnoss.ogg is send as text/plain by the server and that is probably causing it. It works if I save the page and the ogg file and open it locally.

See https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_video_elements

more options

Your response sounds reasonable, except that I can't figure out why Chrome should be responding properly to the very same page when delivered from the server. Shouldn't the Chrome browser be affected in the identical fashion from the .ogg file being delivered as text/plain?

Assuming that you have correctly identified the cause, would it help if I used a "source" statement, <audio controls autoplay> . . . ? Does that force the download to be delivered as audio/ogg?

more options

I have continued to try various alternatives, but still have the problem that the <audio> element works when my site is loaded into firefox from my local disk, but produces a blank control panel with no sound when loaded from a server into firefox.

I now have tried two different servers and re-written the audio element:
  1. 1 www.giammo.com/audiotest
  2. 2 www.crestline-enterprises.com/audiotest

These sites are identical and are using the audio element: <audio controls autoplay> <bgsound src="gnoss.mid"> </audio>

Both sites work perfectly under Chrome - so that I doubt that it is a server-related problem. I suggest that it is somehow a Firefox bug.

Tom Giammo

more options

Firefox needs the correct MIME type. If you load the page locally then there is no MIME typ involved, but loading from internet is different and it will never work in Firefox if the server doesn't send the ogg file with a MIME type that is listed as supported for the audio element (audio/ogg) in the article that I posted above. There is nothing wrong with the original code. Firefox won't play that file if the server sends it as text/plain.

more options

I realize this is an old post, but just in case it's helpful:

Firefox seems to be pickier about validating the files sent to it before it tries to play them than Chrome or the Android browser (for example).

The "mime type" is how the web server announces to the browser what kind of data it's sending, and until recently most web servers didn't know "out of the box" that ".ogg" files are "audio/ogg". If the web server doesn't recognize the file's extension, it'll usually default to announcing that what it's sending is "text/plain" or "application/binary", or something of the sort. Since those aren't types of data that Firefox can play as audio, Firefox just rejects it (even though the actual data being sent is "secretly" just audio/ogg).

If you don't have access to update your web server to recognize ".ogg" files as mimetype "audio/ogg", one possible workaround might be to explicitly specify the mimetype in the <audio> tag:

<audio src="gnoss.ogg" controls autoplay type='audio/ogg; codecs=vorbis'> <bgsound src="gnoss.mid"> </audio>

(This is probably too late to help the original questioner, who by now has presumably found a workaround, but might be useful for people with similar problems...)