Linked by Thom Holwerda on Sun 16th May 2010 12:52 UTC, submitted by mrsteveman1
Internet & Networking Mozilla, sticking to its ideals of the open web, decided long ago that support for the patent-encumbered H264 codec would not be included in any of its products. Not only is H264 wholly incompatible with the open web and Free software, it is also incredibly expensive. Mozilla could use one of the open source implementations, but those are not licensed, and the MPEG-LA has been quite clear in that it will sue those who encode or decode H264 content without a license. Software patents, however, are only valid in some parts of the world, so an enterprising developer has started a project that was sure to come eventually: Firefox builds with H264 support.
Thread beginning with comment 424875
To view parent comment, click here.
To read all comments associated with this story, please click here.
Thom_Holwerda
Member since:
2005-06-29

To re-iterate: If you use the built in functionality of the OS, you are not violating any patent!, you re-use existing functionality, less code to maintain.


Eh, no. More code to maintain.

Code to make use of DirectShow (XP/Vista/7), but since DirectShow is currently being phased out, you need code to support its successor too (Media Foundation). Then you need code to support QuickTime. Then you need code to support Gstreamer (and hope the user has H264 codecs installed on his system, not a given in Linux land).

So, more code.

Reply Parent Score: 2

MacMan Member since:
2006-11-19

I still content that using a set of existing decoders is a lot simpler than writing your own.

Even if you use some existing cross platform decoding library, you still need to tie the out to the windowing system, which is different on OSX, Windows, and X11.

Fine, direct show is being phased out, like I said, I have not been forced to use Windows in a long time, but I'm still assuming that MS gives you a pretty easy way of decoding video. I do know thats it pretty easy to decode a video stream with either the CoreAnimation or QuickTime frameworks, its about 20 - 30 LOC (lines of code) to decode with QuickTime.

Its probably more effort to tie the 3rd party decoder to the native windowing system than it is to use the native decoder. You are also probably shortchanging your users by using a 3rd party decoder as the build in decoders are pretty dammed optimized by Apple and MS. You also have to build, package and deliver any 3rd party libs. On the linux side, just use a package manager to make sure that the existing decoders are installed.

Reply Parent Score: 2

tyrione Member since:
2005-11-21

You still contend.

Reply Parent Score: 3

lemur2 Member since:
2007-02-17

"To re-iterate: If you use the built in functionality of the OS, you are not violating any patent!, you re-use existing functionality, less code to maintain.


Eh, no. More code to maintain.

Code to make use of DirectShow (XP/Vista/7), but since DirectShow is currently being phased out, you need code to support its successor too (Media Foundation). Then you need code to support QuickTime. Then you need code to support Gstreamer (and hope the user has H264 codecs installed on his system, not a given in Linux land).

So, more code.
"

Easier then (in Linux land, at least) to use the decoder embedded into the video card. Two advantages: (1) it is legal on Linux (since the video card is paid for, everyone has an implied license to use it), and (2) you get hardware-accelerated decoding.

Mozilla itself could ship (as open source) a browser that used video decoders embedded within the system's video card hardware (if there is any). No need for forks and clones.

Downside: Doing this just encourages h.264 on the web, which is not in the best interests of the vast, vast majority of people.

Edited 2010-05-16 13:54 UTC

Reply Parent Score: 6

Timmmm Member since:
2006-07-25

Easier then (in Linux land, at least) to use the decoder embedded into the video card.


As far as I know there *is* no 'video decoder' embedded in video cards. There is dedicated signal processing hardware that does things video codecs need to do quickly (like DFTs, colour conversion etc.). But there's nothing that takes H.264 as an input and gives you raw video as an output.

Reply Parent Score: 2

Soulbender Member since:
2005-08-18

Eh no. It's less code to make use of existing media framework and codecs rather than write your own. Unless you're a fan of NIH.

Reply Parent Score: 2

Kroc Member since:
2005-11-10

It’s not as simple as that. Outside rendering, such as with Flash and QuickTime do not act as a native element that you can apply CSS effects to nor layer correctly. HTML5 video acts the same as any image element. To do this, the video decoding has to be part of the browser engine, and this gets particularly tricky around colourspace conversion. HTML5 also provides the ability to get the current frame of a video playing. This sort of thing could prove to be really tricky to do when another thread of another system is doing the video rendering (even in the GPU).

To have any hope of this working cross platform in a reasonable time frame (and not potentially requiring changes to upstream projects) they will have to build the decoder in.

Reply Parent Score: 4

KAMiKAZOW Member since:
2005-07-06

"To re-iterate: If you use the built in functionality of the OS, you are not violating any patent!, you re-use existing functionality, less code to maintain.


Eh, no. More code to maintain.
"

Not true. That code already exists for GStreamer (Songbird uses it, for example).

A Wild Fox release would actually be relatively simple to do: Grab the existing GStreamer patch from https://bugzilla.mozilla.org/show_bug.cgi?id=422540 (developed by Mozilla itself, I may add) and distribute it with GStreamer + GStreamer's DirectShow/QuickTime plugins, and you're done.

Reply Parent Score: 4

cerbie Member since:
2006-01-02

...and not using the native functionality is good how, exactly? I rather like video not using a ton of my CPU, and that requires taking advantage of various fully or partially platform-tied features, right now.

If that's not going to get used, then there's little benefit to using any standard MPEG codecs, and low-power platforms get screwed (in the case of the Atom, you get screwed anyway, but you at least have options to reduce the pain, like ION).

Reply Parent Score: 2

kristoph Member since:
2006-01-01

The interface to a video player is an order of magnitude less work then maintaining the player itself.

K

Reply Parent Score: 1