So, assuming we got a distribution without proprietary codecs installed.
Let's take Linux Mint for example. I want to store and playback wav and ogg format sounds, either by using my own software, or by using another developer's software. So far so good right?
Imagine now that we have the following scenario. For some reason, I wanna playback a file that is either an mp4 or mp3 or mpeg or any other format, made by proprietary codecs. Instantly, I will need a codec for these formats.
I read somewhere that Fluendo sells solutions for "legal codec usage" for linux distros.
URL of fluendo: http://www.fluendo.com/en/
So here comes the questions:
Using VLC and ffmpeg is enough for me to convert a file to an ogg or ogv so I can playback a song or a video using an open format. You can also playback playback files made by proprietary formats. But are VLC and ffmpeg legal to use, to playback such files made by proprietary codecs? For example, ss VLC codecs okay to be used without paying anyone for mp4 playback? Is it okay to convert a file from mp4 to ogv?
If not, are there any legal and open source and free (as in freedom) codecs around that can solve the issue, or does someone have to pay a product, to be ethically correct, to the developers of the proprietaty codecs?
Note that I do not ask for Windows, since codec licenses are included to the price of the operating system. I ask exclusively for a free linux distribution.
Since #LordNeckbeard pointed me to the FAQ of FFmpeg, that I really can't believe I missed, it became clear to me that there is a problem in using proprietary codecs, thus there are some file formats that could be avoided to keep ourselves safe. Otherwise if someone can afford a license to use them too, that would be perfectly fine.
So mp3, mp4, mpeg and some more patented formats are to be avoided, if not licensed.
ffmpeg can be built so it can exclude support for such formats and if you need to use sound or video to your software ogg and ogv are nice and efficient formats as we all know.
Digging a little deeper Ι found that too.
https://www.fsf.org/resources/playogg_radiostation.pdf
In their developer documents, they say they support the following:
• Containers: MP4/CENC, WebM, MPEG-DASH, SmoothStreaming
However, MPEG-DASH and SmoothStreaming are streaming protocols that allow for various containers. The MPEG-DASH spec allows for MPEG2-TS chunks, but I don't see any information regarding supported container formats inside of a DASH manifest.
I think when it says "MP4/CENC", it is implies it supports MP4 containers within an MPEG-DASH manifest. I don't think TS is supported... so no mention of HLS either of course.
Im am going to guess no. The DASH spec does say it supports TS containers, but I have yet to see an implementation do so. DASH was very much a design-by-commity effort, and they included everything into the spec. In fact they included too much. a subset of DASH called 'DASH 264' seems to be what everyone is gravitating toward. Smooth Streaming and DASH 264 use near identical media formats, but different manifest formats. the file format is basically an MP4 with a fragmented mdat interleaved with a moof (http://alexzambelli.com/blog/2009/02/10/smooth-streaming-architecture/). Google includes WebM because of political reasons (trying to push an alternative codec own and thus keep MPEG-LA honest).
In addition, TS is a patent encumbered format. So by including it google would need to pay royalties to MPEG-LA, and I am assuming they are avoiding that extra cost.
Flash video seems stabler and less prone to playback hiccups when the computer's overloaded and busy. Why would this be? I would expect native browser video playback to be more stable and performant, if anything.
I'm in Google Chrome and windows, FWIW.
Flash has established itself for playing videos long before HTML, so if anything I'd expect the browser support to be less stable. After all, video in Flash had years to mature.
Also Chrome apparently does not use hardware-accelerated video decoding by default.
This depends how the video is being streamed. The flash player you are using, might also be compressing the file, or streaming it differently then native html5 video.
How to play single ogv file in IE8 and Safari by HTML5 video?
I known IE and Safari don't support Ogg Theora, but I have a requirement for that.
Any suggestion to me?
Thanks
OGV.JS: AN OGG THEORA AND VORBIS VIDEO DECODER IN JAVASCRIPT
Targeting Safari 6+ and ie 10+
http://badassjs.com/post/71980473022/ogv-js-an-ogg-theora-and-vorbis-video-decoder-in
IE8 can't play any HTML5 video, let alone specific formats. It simply doesn't support it (or any other HTML5 elements). The best you can do is embedding a Flash video. IE9 does support HTML5 video, but still not the OGG Theora format.
Safari explicitly doesn't support it either. It does support HTML5 video, but not the OGG Theora format.
So the short answer is it can't be done. Sorry.
If the requirement is for an open source video format, you might try switching to WebM, which is supported by both Safari and IE9 (although both require the relevant video driver to be installed separately to the browser) as well as Chrome and Firefox. (See http://caniuse.com/#search=video)
IE8 simply isn't going to work for you though, no matter what format you use. It simply doesn't know what the HTML5 video tag is, and there's not much you can do about that.
Cortado streaming applet
Cortado is an open-source cross-browser and cross-platform video playback solution based upon Java technology. Leveraging the huge installation base of Java it allows web-authors to deliver Ogg Theora content without having to worry about the media playback setup installed on customers' machines. This enables e.g. Wikipedia to deliver Ogg Theora video content embedded into articles to millions of users. Originally developed at Fluendo, Cortado's latest versions are now maintained by Xiph.org. If you're interested in using free media delivery technology, e.g. to avoid the costs adjunctive to non-free technologies like H.264, and want to reach a big potential user base, Cortado may be the solution you've been looking for.
http://theora.org/cortado/
Is there a particular reason why Firefox does not support playback of MP3 files in <audio> elements, only Ogg format?
Is it a licensing issue?
Are there any plans made for a possible future implementation?
Is it possible to develop an addon to support MP3 playback in <audio> elements?
Update October 2012: Wooohooo! Brendan Eich just announced on his blog that work for MP3 and H264 support in Firefox is underway. You can track the work on BugZilla: Support H.264/AAC/MP3 video/audio playback on desktop Firefox
Update February 2013: After much heavy lifting from Firefox developer Chris Pearce, this patch flips the switch to enable MP3, MP4, H.264, and AAC playback by default in HTML5 <audio> and <video> elements when running on Windows 7 and later. We should see some native web MP3 support in the next stable FF release.
Update April 2013: Woohooo! The latest stable Firefox has experimental support for MP3. To turn it on, type about:config in Firefox, find media.windows-media-foundation.enabled and set it to true. Restart Firefox, and you're all set; go to a site with HTML5 audio (e.g. my radio site) and you'll see Firefox is indeed playing the native MP3 and not resorting to a Flash fallback.
Update May 2013: At last! Firefox 21 was released today, and it includes native HTML5 MP3 support on Windows. I just verified it supports native MP3 audio out-of-the-box, provided your operating system supports it. I tested on Windows 8, but I believe this will automatically work on Windows 7 and Vista.
Update December 2013: Firefox 26 was released today, which gives native MP3 audio support for all versions of Windows going back to Windows XP.
The currently-accepted answer by Ian Devlin is obsolete. The new answer is: while Firefox has historically not supported native MP3 playback for licensing reasons, this will change in the future; we'll soon see a Firefox that plays MP3 natively via the HTML5 <audio> tag.
In March 2012, Mozilla did an about-face on this issue, stating publicly they'll support MP3 and H.264 in their native HTML5 implementation, provided the codec is already available on the end user's system.
In the linked article, Mozilla's director of research, Andreas Gal, makes the following public statements:
“We will support decoding any video/audio format that is supported by
existing decoders present on the system, including H.264 and MP3.
There is really no justification to stop our users from using system
decoders already on the device, so we will not filter any formats.
I don’t think this bug significantly changes our position on
open video. We will continue to promote and support open codecs, but
when and where existing codecs are already installed and licensed on
devices we will make use of them in order to provide people with the
best possible experience.”
This is in contrast to their previous position, which didn't attempt MP3 and H.264 playback even if the operating system supported it.
Bottom line: Firefox will eventually support MP3s in its HTML5 <audio> implementation. As of September 2012, I see no information about when this will happen. It appears to be under development for Firefox on Droid; I speculate we'll see support in desktop Firefox soon afterwards. Edit October 2012: Indeed, this speculation was correct: native MP3 and H264 playback in desktop Firefox is now under development.
Licensing issues: HTML5 video and H.264 – what history tells us and why we’re standing with the web and Mozilla defends Firefox's HTML5 support for only Ogg Theora video (despite their titles, they both also talk about MP3 licensing, albeit briefly).
All you can do is fall back to Flash and play them through that.
UPDATE: Native MP3 (and H264) support is now available on desktop Firefox version 20+
I'm using it to follow podcasts, and the occasional mp4 video, too.
If it doesn't work, there's an hidden option to enable:
about:config → media.windows-media-foundation.enabled → true
It also works with HTML5 YouTube
(that should anyway use webm, but might be more fine tuned for h264)
MP3 usually is a Fraunhofer/Thomson patents problem. They sell their licenses on the slightly shady mp3licensing.com domain.
Regarding patents (update 2016/6) (Wikipedia):
The basic MP3 decoding and encoding technology is patent-free in the
European Union, all patents having expired there. In the United
States, the technology will be substantially patent-free on 31
December 2017 (see below). The majority of MP3 patents expired in the
US between 2007 and 2015.
and
[...] patents expire 20 years after the initial filing date, which can be up
to 12 months later for filings in other countries. As a result,
patents required to implement MP3 expired in most countries by
December 2012, 21 years after the publication of ISO CD 11172.
As to patents finally expire in the US in December 2017:
Except for three patents, the US patents administered by Sisvel had
all expired in 2015, however (the exceptions are: U.S. Patent
5,878,080, expires February 2017, U.S. Patent 5,850,456, expires
February 2017 and U.S. Patent 5,960,037, expires 9. April 2017.
as well as
[...] the MP3 technology will be patent-free in the United States on 30
December 2017 when U.S. Patent 5,703,999, held by the
Fraunhofer-Gesellschaft and administered by Technicolor,
expires.
There is software circumventing those patents, like the LAME MP3 encoder, but they do that by distributing only in source code form.
The LAME developers state that, since their code is only released in
source code form, it should only be considered as an educational
description of an MP3 encoder
Then there are binary distributions of LAME, and, as you can easily see from the domain, they originate from Argentina. This can happen because MP3 patents are deemed invalid in many countries where the very concept of software patent was never legislated upon.
(I'd like to have an exhaustive list of countries, but the situation evolves quite rapidly, and I don't even known what side of the soft-patents divide my country stands in. That's not a level of uncertainty Mozilla wants to cope with)
Then again, Mozilla may have found THEIR way around the patent problem.
It's not perfect. (i.e. it leaves linux in a puddle of mud)
Andreas Gal, Mozilla’s director of research wrote:
(but the discussion revolved around B2G, really read the whole article to form an opinion)
“We will support decoding any video/audio format that is supported by
existing decoders present on the system, including H.264 and MP3.
There is really no justification to stop our users from using system
decoders already on the device, so we will not filter any formats,” he
wrote. “I don’t think this bug significantly changes our position on
open video. We will continue to promote and support open codecs, but
when and where existing codecs are already installed and licensed on
devices we will make use of them in order to provide people with the
best possible experience.”
So, from what I see:
On Windows and Mac (using, already licensed by the OS, dlls/dylibs) Mozilla could end up supporting MP3.
On Linux... I'd like to know. Maybe in selected countries, you'll end up installing some unlicensed libs and get away the way Audacity does.
There's a light at the end of a tunnel, but let's just hope it's not a fast approaching train.
Taken from Wikipedia, for MP3:
MPEG-1 or MPEG-2 Audio Layer 3 (or
III), more commonly referred to as
MP3, is a patented digital audio
encoding format using a form of lossy
data compression.
Taken for Ogg:
Ogg is a free, open standard container
format maintained by the Xiph.Org
Foundation. The creators of the Ogg
format state that it is unrestricted
by software patents and is designed to
provide for efficient streaming and
manipulation of high quality digital
multimedia.
Mozilla doesn't want patent issues, so Ogg was chosen as the better candidate.
It is possible to make such an implementation, so that Firefox can play mp3 in <audio> tag, but this won't be done because of issues I mentioned.
Sometimes politics, and other real world issues, dictate what gets implemented and what doesn't.
For Linux to turn on HTML5 streaming for MP3, MP4, H.264, and AAC, you got to set media.gstreamer.enabled to true into about:config!
Gstreamer is present in most, if not all, Linux distributions!
I believe that the Mozilla developers decided against implementing MP3 support, in order to avoid paying for patent licences from a number of organisations (Technicolor/Thomson Consumer Electronics, the Fraunhofer Institute, Alcatel-Lucent, Sisvel and potentially others, from what I can gather).
Decoding of various audio formats, including MP3 files, can now be done in modern browsers using JavaScript. http://audiocogs.org/codecs/mp3/
If a site used this kind of code (or a Firefox add-on did), Firefox would play MP3 files just fine.
As already said it's a patent problem. There are already plenty of open source MP3 decoders and encoders implementations (among them are LAME and FFmpeg), the problem is that to ship binaries somebody has to pay for the patent license. Here's a quote from LAME wikipedia article confirming this:
Like all MP3 encoders, LAME implements some technology covered by patents owned by the Fraunhofer Society and other entities. The developers of LAME do not themselves license the technology described by these patents. Distributing compiled binaries of LAME, its libraries, or programs that derive from LAME in countries that recognize those patents may be patent infringing.
The LAME developers state that, since their code is only released in source code form, it should only be considered as an educational description of an MP3 encoder, and thus does not infringe any patent by itself when released as source code only. At the same time, they advise users to obtain a patent license for any relevant technologies that LAME may implement before including a compiled version of the encoder in a product.
Mozilla obviously cannot afford to pay patents for any copy of Firefox that gets downloaded.
The two possible solutions are:
use external codecs already preinstalled in the system Firefox is installed in. This solution is the one that has been adopted when running in Windows as mentioned in this other answer. In this case, if the Microsoft MP3 codec is used, Microsoft is the one who paid for the patent license, cost which is part of the Windows license;
wait for MP3 patents to expire. The last one will probably expire on April 16, 2017 which is roughly 3 years and a half from now, but time passes steadily! Firefox 1.0 came out on November 9, 2004, which is more than 9 years ago!
That's why using patent free codecs is, from a user perspective standpoint, more desirable!
2017 UPDATE: patents have expired and open source projects are now starting to pick up MP3 support, e.g. Fedora. Let's hope Firefox does the same soon!
It's now 2020 and I got this issue on Firefox 83.0 on Windows 10. At first I thought my issue was with my profile being too old, from the Firefox 2.x era maybe, and that I got some leftovers such as the mentioned in other answers media.windows-media-foundation.enabled. Unfortunately that wasn't the case.
After searching for a bit in about:config for media decoding, playback and MP3 codec configurations I've found the culprit: media.ffvpx.mp3.enabled. It was set to true and that was preventing a podcast from playing, with Firefox complaining about not finding any compatible codecs to play an audio/mp3 file. Just toggled it false and refresh the podcast page and it started working fine.