Closed Bug 475110 Opened 15 years ago Closed 15 years ago

Non PCM encoded Wave files do not play

Categories

(Core :: Audio/Video, defect)

1.9.1 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: streetwolf52, Assigned: kinetik)

References

()

Details

(Keywords: verified1.9.1)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090123 Shiretoko/3.1b3pre (.NET CLR 3.5.30729)

The URL I specified contains wave files which are encoded in several different ways.  The files designated as PCM play natively.  All the others do not play.

I specified that wave files play in WMP but the non-PCM files do not open WMP or any other program I put in the Applications option.  However, I discovered that if I change it to a plugin for audio/x-wav such as the Quicktime plugin and then change it back to WMP all the files open in WMP.  I just have to move my pointer to the plugin then move it to WMP and click OK.  

This only lasts for the life of the session.  Once I exit FF the problem happens again.  This 'workaround' only works if there is a plugin associated with this MIME.  

Reproducible: Always

Steps to Reproduce:
1.see details
2.
3.
Actual Results:  
Non-PCM encoded wave files don't play

Expected Results:  
All Wave files should play.
Version: unspecified → 3.1 Branch
confirmed with Seamonkey 1.9.1 branch.
The internal video/audio component takes the wav files, doesn't display any controls which is really ugly in the case of such a standalone file and it doesn't play non-pcm wave files.
Status: UNCONFIRMED → NEW
Component: General → Video/Audio
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → video.audio
Version: 3.1 Branch → 1.9.1 Branch
The HTML5 specification only requires the internal audio element to playback PCM encoded wav files:

http://www.whatwg.org/specs/web-apps/current-work/#audio

"User agents must support the WAVE container format with audio encoded using the PCM format."
As I said I can't set another application to handle waves unless I use my workaround as described.  So this might be an additional problem.
I just want to add that in my case my online VOIP voice mail is a GSM wave file. It does not play.  I can accept the HTML5 specification but non-PCM wave files should at least open in the Program I specify in the Applications options. 

I didn't mention that the controls become visible when I move my pointer to the upper left hand side of the blank screen.  They don't do anything however.

So the problem might not be that non-PCM wave files are not being played natively but that they aren't being played by external programs or plugins without using my workaround.

Perhaps a new problem report should be created for this?
I don't understand why my bug appears to be dead in the water.  There are so many sites that use non PCM encoding.  FF at it stand now won't even let me play them in another application such as WMP.  Also, HTML5 states that it must support PCM format not that other formats can't exist.

Please rethink this.

Thanks.
>I don't understand why my bug appears to be dead in the water.
To give you a feeling about timeframes in bugzilla : this 3 month old bug is a very, very young bug, we have thousands of open bugs that are 2 years or older.
I think a new bug should be created for comment 4. Could you be more specific about what non-pcm based formats you want supported?
The URL I provided at the top contains just about all the ways a Wave file can be encoded.  I'd like to see all of them supported either natively or at the least be able to click on a non-PCM wave and have it opened in my media player which used to work but doesn't work now.  All other browsers can play all the wave files, btw.

The GSM encoded waves I believe are used to record my voice mail I listen to online.  Clicking on it just produces a screen with the video controls which is also seems shouldn't happen.

In a nutshell sites use all of the methods above to encode their waves so why not support them all?  Even if HTML5 says no more non-PCM encoded wave files you can't just stop all the sites that use them dead in their tracks so to speak.
Apparently the formats of the .wav files on that nch.com.au website are:

file 8kulaw.wav 
RIFF (little-endian) data, WAVE audio, ITU G.711 mu-law, mono 8000 Hz
How will Firefox 3.5 handle non-PCM .wav files?  If the files are not played, IMO that is a significant regression over the out-of-the-box experience of Firefox 3.0 on Mac, which uses the QuickTime plugin.  (From Gary's comments above, it sounds like it's a regression on Windows as well.)  I can confirm that our web-based voice mail system at work uses non-PCM .wav files:

http://www-01.ibm.com/software/pervasive/unified_messaging/

Listening to messages works by default with Firefox 3.0 and with Safari, but it's broken in Firefox 3.5 Beta 4.  At the least, I think that when Firefox 3.5 encounters a non-PCM .wav file, it should provide an easy way for the user to switch back to the Firefox 3.0 behavior (i.e., the use of the QuickTime plugin).  Otherwise, I think many novice users will get very frustrated.
I think that when a natively handled mime type is loaded and it contains an unsupported format (audio/x-wav with a compressed encoding, or a video/ogg with an mp3 audio stream if that's possible) it should fall back to plugins if available. Please file a new bug for that (see comment 7 and comment 4).
I submitted bug 491487 on the fall back behavior.  I'll leave it to someone else to decide if it should be blocking-1.9.1.
Flags: blocking1.9.1-
It's very difficult to hand off playback to another application after we've decoded some quantity of the data and discover that we don't understand the particular codec used.

You can set the media.wave.enabled pref to false, but that's not a great solution. I'm not really sure what to do here.

Manu, what Wave codec is IBM using?
This is an example WAVE file from my work's web-based voice mail system that doesn't play in Firefox 3.5.
Is this served via an <object> element? Or as a link that opens an external app?
Attached patch fixSplinter Review
This patch stops us from loading Wave files as stand-alone documents (in <object> or top-level documents). Wave files can still work in <audio> and <video> elements.
Assignee: nobody → roc
Attachment #379028 - Flags: review?(chris.double)
Attachment #379028 - Flags: review?(chris.double) → review+
Comment on attachment 379028 [details] [diff] [review]
fix

This patch fixes a regression for people using Wave files on the Web with codecs we don't support. For Wave files appearing in <object> or loaded directly into a tab, We're just going to pretend the browser doesn't understand Wave files and hand them off to a plugin or helper app, like Firefox 3 did. Apparently some products depend on this.

It doesn't affect <audio> and <video> elements, we'll still use our own Wave codec there, but there are no issues of compatibility with existing content there, of course.

There's not real loss of functionality for users since almost all systems can play Wave files one way or another.
Attachment #379028 - Flags: approval1.9.1?
Whiteboard: [needs landing][needs 191 approval]
In response to comment 16, in the voice mail app there are direct links to the .wav files; there is no <object> element involved AFAIK.  If I'm wrong I'll post another comment.
Please, please fix this.  All the other browsers will play any encoded wav file PCM or not.  To lose this functionality in FF is not acceptable.
Comment on attachment 379028 [details] [diff] [review]
fix

a191=beltzner
Attachment #379028 - Flags: approval1.9.1? → approval1.9.1+
http://hg.mozilla.org/mozilla-central/rev/cd1e60567ff3
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing][needs 191 approval] → [needs 191 landing]
Target Milestone: --- → mozilla1.9.2a1
Roc, I cannot get it to work on XP with all the listed wav files on http://www.nch.com.au/acm/. Nothing gets played with todays nightly builds of Minefield and Shiretoko. There is even not a save as dialog.

For me this is not fixed. Or am I doing something wrong?
Henrik, do you have appropriate plugins to play the files?  With a build including this patch, visiting the URLs linked from the bug URL play the media files back via the QT plugin on OS X.

Since we're reverting to platform-specific behaviour in this case, you should see the same behaviour that you see in Firefox 3.0.
I see the same thing as Henrik, no save as dialog when clicking on one of the wave file. But with Firefox 3.0, the save as dialog appears.

I have no plugin installed that can handle audio/x-wav
Matthew, given by the os/platform I thought this is Windows only so I haven't give an UA. Everything works fine on OS X and Linux but not with Shiretoko and Minefield on Windows.

Reopening bug for clarification and further work.
Status: RESOLVED → REOPENED
Keywords: fixed1.9.1
OS: Windows Vista → All
Hardware: x86 → All
Resolution: FIXED → ---
Doesn't appear to be working as I expected. I have both media player and QT on the application list for wav files.  Even though I have Media Player as the default all wav files are played in QT.

Secondly QT plays all wav files including PCM.  I thought PCM waves would be played natively.  If I disable the QT plugin I get native PCM playback and Media Player is ignored so all I get is the throbber for non-PCM files.

Definitely something is askew.
Comment on attachment 379028 [details] [diff] [review]
fix

(clearing flag for query-sanity; the patch can stay, as it's obviously better if not yet fully fixed)
Attachment #379028 - Flags: approval1.9.1+
Got a fix, but I'm not sure why it's only broken on Windows.
Assignee: roc → kinetik
Don't register Wave MIME types with the doc loader.  I don't know why this bug only occurs on Windows (differences in content sniffing?), but it's clear that we shouldn't be registering these MIME types when we have no intention of handling them.
Attachment #380029 - Flags: superreview?(roc)
Attachment #380029 - Flags: review?(roc)
Attachment #380029 - Flags: superreview?(roc)
Attachment #380029 - Flags: superreview+
Attachment #380029 - Flags: review?(roc)
Attachment #380029 - Flags: review+
Comment on attachment 380029 [details] [diff] [review]
additional patch v0

very safe followup fix
Keywords: checkin-needed
Whiteboard: [needs landing]
re comment #28:
The 2 plugins case which are handling the same mime-type is the old behavior.
You can not control which plugin plays the mime-type, there is no default and it depends on which plugin is found first (?) on the hdd. The plugin manager bug is for setting a default in such cases.
Pre-approved to bake on trunk.
Whiteboard: [needs landing] → [needs landing][approved for -central baking]
http://hg.mozilla.org/mozilla-central/rev/965f6ed804a6
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing][approved for -central baking] → [needs 191 approval][approved for -central baking]
Ok, I've checked with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090601 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090601041706 and everything is fine on Windows now.
Status: RESOLVED → VERIFIED
Comment on attachment 380029 [details] [diff] [review]
additional patch v0

a191=shaver, please land ASAP!
Attachment #380029 - Flags: approval1.9.1? → approval1.9.1+
can someone look at this, (sorta related) https://bugzilla.mozilla.org/show_bug.cgi?id=470518
Whiteboard: [needs 191 approval][approved for -central baking]
Verified fixed with a 1.9.1 build on Windows Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090604 Shiretoko/3.5pre (.NET CLR 3.5.30729) ID:20090604045218
See Also: → 994605
You need to log in before you can comment on or make changes to this bug.