When I open an audio stream (e.g http://ct1.party107.com:8000/Party107-Q0.ogg ) and then right-click on the player, I get options like:
'view video', 'copy video location', etc. Those should be 'play audio', 'copy audio location', 'save audio', 'send audio', etc.
This is mostly merely cosmetic, but note that when people click 'view video' and then get no video (which they will do) some of them will assume the stream contains video and blame us for not playing it.

This is actually substantially worse than I originally thought. Open an ogg audio file on the web (such as the one in the URL field). Not only does the right-click menu say 'save video as', it actually changes the file extension of the file, which is going to break a fair number of things when people try to reopen it later.
In other words, when I right click on the audio file above, this is what happens:
* says 'save video as'
* saves it as Party107-Q0.ogg.ogv
It should:
* say 'save audio as'
* save it as Party107-Q0.ogg (no new, and incorrect, .ogv extension.)

Some more info on this bug...Right click the page, select Page Info > Media...the metadata for the test file shows that it is a video.
Using a different source: http://www.vorbis.com/music/
It appears that Firefox detects these as videos as well. I think the issue here isn't that Firefox is saving audio as video, it's that Firefox is detecting/handling .ogg audio files as video from the get-go.

Created attachment 539606[details][diff][review]
Patch v1 - Better handling of media (audio/video) saving
Here is a patch that address the problem for the saving part. It's not finished, though.
The thing is that the mime type for the media is application/ogg, and this could be audio or video. And sometime, when viewing an ogg video, it is served with a audio/ogg MIME type (example : http://ftp.akl.lt/Video/Big_Buck_Bunny/big_buck_bunny_720p_stereo.ogg).
As no content type is provided when saving a media, relies on the system to find what extension it should use for the file name, and it was deducing video/ogg.
I had the same problem saving from an audio tag.
Specifically, we should not display a video frame when we are only playing audio (a quick way to do that would be to check the video dimension in the metadata), and treat the media as audio (for the context menus).
I'm going to address the other issue we encounter in some other patch.

Created attachment 539790[details][diff][review]
Patch v1 - Better handling of media (audio/video) saving
I've added audio / video detection for the context menu when a ogg file is loaded without an audio tag. I've tested quite a few cases, and it seem to work quite well (and it even works when the media is served with the wrong mimetype).

I've tried to dig a little deeper to fix the "audio treated as a video" problem as its root source, and I face a problem.
In content/html/document/src/VideoDocument.cpp, when the fake <video> element is instantiated, we cannot know if we need a video or an audio element (if it is ogg served with an application/ogg, it can be both video and audio only, and we haven't got data to choose), so we are not able to instantiate an <audio> element instead. The <video> element must then mimick an <audio> element, by changing the context menu (as it is currently done), and by finding a way not to draw the video rendering frame. But this is probably a nitpick.

Comment on attachment 539790[details][diff][review]
Patch v1 - Better handling of media (audio/video) saving
Justin, according to "hg annotate -u", you seem to be the person that have modified this file the most. Feel free to point me to a more appropriate person if you can't/don't want to do this review.

Created attachment 544218[details][diff][review]
Patch v3 - Addressed dolke concerns
> Hmm, why is this even OGG specific in the first place? Can't WebM have the same > problem?
WebM cannot (as far as I know) contains only audio, so the MIME type check works, without having to rely on other checks.
Also, I've removed quite a few tests, and added a |readyState >= 1| check when we are testing against metadata.
> What's this change for?
Nothing, I can't even remember why I wrote that in the first place.

(In reply to comment #15)
> Oh, I didn't event know that .weba possible, thank you for pointing that out.
> I'll update my patch tomorrow.
It's not that clear to me
There are still some discussions about the opportunity of having audio only for WebM as far as i understand

(In reply to comment #16)
> (In reply to comment #15)
> > Oh, I didn't event know that .weba possible, thank you for pointing that out.
> > I'll update my patch tomorrow.
>
> It's not that clear to me
>
> There are still some discussions about the opportunity of having audio only
> for WebM as far as i understand
We support the audio/webm mimetype and don't do anything to make playback fail if there's no video stream, so something at least is possible. Whether it's a good idea (audio-only WebM provides no additional features over plain Vorbis-in-Ogg, and breaks compatibility with over a decade's worth of existing software and hardware deployment) is a separate question.

Hmm, I wonder if webm/weba is actually likely to have this problem. OGG is a bit of a special case, because it seems people commonly just use ".ogg" for both, instead of .ogv/.oga. Maybe we should wait to see if people actually start using ".webm" for audio-only content before giving it the same treatment. With this current patch, I think <video src="foo.weba"> should correctly offer "Save Audio As" and not result in foo.weba.webm.

After testing the behavior using both .weba and .webm extension, with this patch applied, it goes like this, considering a file with no audio information :
- If the media ends in .weba, in both <audio> and <video> tags, the right click context menu show "Save audio", as expected. This menu has "Save audio" as title, and the file type filter shows "All file", as is the extension was not recognized.
- If the media ends in .webm, everything works (context menu, save file window title), but the file type filter shows "Web Media Video".
In all cases the file names are correct (i.e. are respecting the original src attribute value).
(test page here : http://paul.cx/test/webm.html)
Justin, I'll write a test for this, and address your last comments.