GPL'd Driver and Linux Support For New H.264 Capture Card 119
azop writes "Almost a year ago Slashdot covered the story of a MPEG-4 multiple input capture card with a GPL Video4Linux licensed driver. Earlier this year, Ben Collins added H.264 support into the solo6x10 Video4Linux2 GPL driver. The H.264 PCIe cards are finally released and shipping to customers. The new cards support faster frame rates and sport a PCIe interface. The driver is available for forkin' on Github."
Software / Firmware (Score:5, Insightful)
Why is it important that linux drivers have source available but we don't worry so much about seeing the firmware source? Should we be pushing to see firmware source too? Instead should it not matter about seeing driver source? I'd love to hear your perspectives.
Re: (Score:1)
Firmware is on the device, the drivers are on my computer.
Re: (Score:2)
We're talking about on already-general-purpose PCs. Alternative firmware is very useful on artificially limited devices like phones, and apparently routers
Re: (Score:2)
We're talking about on already-general-purpose PCs. Alternative firmware is very useful on artificially limited devices like phones, and apparently routers
Personally, I won't rest until every last ounce of source-code is available for my machine. Direct Memory Access (DMA) + Firmware Binary Blobs == Unknowable behavior. This is one reason I applaud AMD's support for CoreBoot. [wikipedia.org]
No, I'm not paranoid, but, yes, we probably should be -- I've just been burned too many times by MFGs dropping support for things to enforce art
Re: (Score:1)
Their "support" of coreboot is only for show. We had to drop using linuxbios/coreboot on our quad core systems because it wouldn't boot correctly (read: at all.) We had the same problem with the previous gen dual core systems -- for unknown reasons 7% would not work. Only after buying a source license for AMI(?) BIOS ($$$$$) did we find them flipping several undocumented, reserved bits which were the difference between unstable/unbootable and a fully functional system. [ALL of them work perfectly when bo
Re: (Score:2)
I don't see where you've contradicted the parent.
Re:Software / Firmware (Score:5, Insightful)
That doesn't mean firmware can not do evil things. Or does not need any quality vetting or so.
The BIOS is a kind of firmware too, and there exist viruses that can exploit certain BIOS firmwares and to all kinds of bad things to your computer. Not sure about this specific piece of hardware but I'm quite sure that the trend is towards more and more reprogrammable firmwares, if only to fix bugs after release.
Anyway I'd say the firmware is about as important as the OS driver. And having the source of the firmware will no doubt provide information to driver developers on how the device really works.
Re: (Score:2)
So you've really asking why we can't see all firmware code for all devices and peripherals, including BIOS, but also firmware for all devices in our computers like optical drives, HDD's, video cards. What about keyboards and mice, which probably also have some firmware code in them too by now?
Re:Software / Firmware (Score:4, Insightful)
Indeed.
And the question on why we can not see (most) firmware source code will probably the exact same answer as why we can't see (most) driver source code: patents, copyrights, proprietary algorithms, DRM, whatever.
Yet the biggest risk lies in the devices where firmware can be changed ("flashed"), and where the device and its software must provide certain security against that happening unauthorised. There exist at least proof-of-concept BIOS viruses, maybe also actually malicious BIOS viruses. There is no reason why such viruses could not target other parts of the computer, such as hard drive firmware to hide themselves.
Re:Software / Firmware (Score:5, Insightful)
Often the firmware is what turns a bunch of cheap standard parts into a real product. Unless you want to go open source hardware, too, you need to keep your firmware proprietary, because most of the engineering is actually part of the firmware and pcb layout is just a small part of your product. And it is easy to do a compatible pcb from the scratch.
Re: (Score:2)
Re: (Score:2)
just as myself and most of my customers use Win 7 HP because we don't need the features (the only one I cared about was XP Mode, and that was easily enough replaced with VMWare Player for free)
But where do people with Windows 7 Home Premium get the Windows XP license to run inside VMWare Player?
Re: (Score:2)
YMMV, legality not tested.
Re: (Score:2)
OEM license transferability or lack thereof (Score:2)
Seriously, almost every computer sold between 2001 and 2010 came with a WinXP license
I thought OEM licenses weren't fully transferable. They appear to be restricted to a single PC according to this page [microsoft.com].
Re: (Score:2)
Came with an OEM XP license most likely, which can't be transferred to another computer legally.
Component to which the license is tied (Score:2)
Re: (Score:2)
the ONLY difference between the two was the firmware, which switched off some of the stream processors in the HD4830. This is good for the consumer as they have different price points
Nonsense. Being sold a deliberately crippled product is not good for the consumer.
Re: (Score:2)
Re: (Score:2)
I used to think the same thing, that turning off features is an evil thing.
But now, I realise that is what allows us to get cheaply hacked hardware that's about 5-10% better than what we paid for. The richest subsidises the rest of us. If all they do is change firmware, instead of tracecutting or burning fuses, then we can have what they do.
So go ahead, it gives us cheaper, better hardware. Or buy open source hardware like in article.
Re: (Score:2)
Do you want to pay the same price for the entire 4800 series?
Yes. It costs the same to produce either way, so it should cost the same to buy. If ATI had to sell the same card to everyone at the same price, they'd have to sell it at a reasonable price for everyone or they wouldn't sell any.
Re: (Score:1)
So, you are just being naive.
Re: (Score:2)
No, I just want what's best for the consumer. If you think price discrimination is good for anyone except capitalists, you're not just naive, you're a sucker.
Re: (Score:1)
You are naive AND you want what is best for the consumer (actually, usually this means what is best for you, but I'll let that point be). The two aren't mutually exclusive, but if you can come up with a plan that allows ATI to be better for the consumer (both short and long term) I'm sure they'd be happy to do it.
Unfortunately, your armchair naivety doesn't work in the real world. When you finish growing up and you realize the world isn't black and white, and the easy thing isn't often the best thing, per
Re: (Score:1)
Well...
http://www.gnu.org/licenses/gpl-faq.html#GPLHardware [gnu.org]
Re: (Score:2)
Will non-free firmware taint the kernel?
Re: (Score:3, Interesting)
it can be an FPGA, or even sillicon hard.
I work with this device and it boots up without any kind of ROM or firmware upload.
In this case, would you like the VHDL to be open?
If that's the case, why not ask intel/AMD/... to release the VHDL for their current lineup?
Re: (Score:2)
I think the term you're looking for there is ASIC:
http://en.wikipedia.org/wiki/Application-specific_integrated_circuit [wikipedia.org]
Re:Software / Firmware (Score:5, Insightful)
Open firmware is also good, but take it one step at a time eh?
An open source driver for this is great news because it means the driver, and therefore the card, can be rebuilt for different architectures, can be enhanced over time, can do all the stuff that's great about open source. Not to mention serving as a learning aid for others.
Open firmware would be a bonus because then people have the ability to alter the behaviour of the card itself. Some people do care about this stuff so you have projects like Openmoko's Neo phones. There are also sometimes license problems related to distributing closed firmwares if the OS needs to load them into the device.
Driver source is more important IMHO, for now, because without it (or reverse-engineered OSS drivers) some of my projects with linux on ARM would not have been possible. One example was a wireless USB card attached to an NSLU2. Windows drivers through the old ndiswrapper were no good, it's only when open source drivers were available I could proceed.
Also not necessiarly that useful (Score:4, Funny)
Depends on the device but the firmware may well be something that isn't very accessible to users. For example if the device uses an FPGA, which many do, then the firmware might be the FPGA programming. Ok fair enough, but do you have the Xilinx development software and hardware, not to mention expertise, to mess with it? Not nearly as easy or cheap as firing up a compiler and messing with a driver.
Even if not, if the firmware is just code for something onboard kinda like a BIOS/UEFI on a PC, it could still be pretty difficult for users to deal with.
There's also the issue of bricking the device. Messing with the driver might screw up the OS if done badly enough, but the device should be fine. However messing with the firmware could render the device unusable, and depending on how bad it was messed up could render it unfixable in that you couldn't flash a stock firmware back on it.
Too much risk for not much reward overall, which is probably a big reason not to do it.
Re: (Score:1)
If it's possible to brick the device with bad firmware, then the device is defective.
To be frank, I consider making devices fragile enough to have an allergic reaction to the wrong firmware as just another form of DRM slightly more subtle and more insidious than tivoization.
Either make it so that bad firmware can't wreck the device, or publish all the specs a homebrewer will need to properly manage the device.
Re: (Score:3)
Look, the device needs to have a way to update its own firmware, right? Usually this is in code, in the firmware. If you overwrite the firmware, and you fuck this part up, you can't update over your FUBAR custom firmware. The general public considers this "bricked" because they don't want to start soldering stuff to the JTAG terminal or whatever.
Consider this wild notion:
Allow all the firmware except the bootloader to be overwritten by the bootloader. Then if you brick it, you can still use the bootloader to fix it.
Re: (Score:2)
Bingo.
Re: (Score:2)
Me? No I don't have that expertise.
But others do and may wish to play with it, may even do some cool stuff. Of course they may also do risky things, brick devices, burn them out, whatever else.
This is where "disclaimer of warranty" comes in, IMHO. Perfectly fair to say something like - "Here's the source for the firmware, if you change anything and flash your own version your warranty is over. Happy Hacking"
Re: (Score:2)
There's more as well. Patents, yay. The hardware mfg may have license to use them, but they do not have permission to extend that license to others.
Re: (Score:2)
Personally I don't have the experience to do such programming, and I guess that accounts for most (almost all) people on /.. I don't even know how to hack my own driver. I can barely understand a simple C program.
Still I think it's a good thing to have the source available. People can often do really cool things with it - lots of creative minds wanting to do crazy things the device maker never thought of, or simply want to scratch an itch, and the greater public (including me) can benefit from that.
Re: (Score:2)
Personally I don't have the experience to do such programming, and I guess that accounts for most (almost all) people on /.. I don't even know how to hack my own driver. I can barely understand a simple C program.
I don't even know where I am! What's this big glowy panel in front of me? Does this button do something?
Re: (Score:2)
Another reason is licensing limitations.
A lot of the more complex devices (WiFi, Bluetooth, programmable NICs, etc) often run another OS to manage them. There's often no license to distribute the necessary source, nor is there any way to rebuild it without requiring the proprietary development environment.
It's usually some sort of RTOS. So no, firmware isn't just a simple program that starts at main() and handles requests from the host - it can often be handling real-time processing and many other tasks sim
Re: (Score:2)
Why is it important that linux drivers have source available but we don't worry so much about seeing the firmware source?
When your operating system changes in a way that breaks the driver (or you want to use the card on a completely different OS), you can adapt the driver to your new system. From this perspective, it does not matter what is in firmware and what is in hardware.
Re: (Score:2)
The firmware is platform neutral and is a part of the card itself. If you have the card, you have the firmware and as long as you have a driver, you can use it. If you don't have the card, the firmware doesn't matter much.
OTOH, it is entirely possible to end up having the card, but not having a driver for your OS. In that case, you mights as well not have the card either.
Meanwhile, if you update your OS, and you have a GPL driver, you can update it as needed. The firmware won't get in the way.
All that said,
Re:Software / Firmware (Score:5, Informative)
Re: (Score:2)
AFAIK, Windows isn't released with any firmware on the release CD either.
Re:Software / Firmware (Score:5, Insightful)
Re: (Score:2)
A lot of drivers upload a chunk of firmware to devices when they load. All that's actually on the device is a burnt in bootstrap to let them do that.
Re: (Score:2)
AFAIK, Windows isn't released with any firmware on the release CD either.
On what do you base this claim? afaict many drivers contain firmware and windows contains many drivers (most of which afaict were not written by MS) so i'd be very surprised if their wasn't firmware on the windows CD.
Re: (Score:2)
Re: (Score:2)
Make one. We have rich tool-sets for compiler development. The specs are all we really need -- Give us the hardware specs (instruction tables, register layouts, etc) and we can build compilers. Having to reverse engineer a processor, and then build firmware for it is a pain in the ass. It would be nice if the MFG just shared their tools & sources with us -- then they could benefit from our improvements, but hey No one ever accused them of being benevolent and customer friendly.
It would be nice if
That's difficult when (Score:2)
Make one.
That's difficult when the CPU core you licensed uses an instruction set that is "proprietary and confidential", or the revenue from additional sales to Linux users wouldn't cover the cost of developing free build tools.
It would be nice if the hardware vendors stopped worrying about software "thieves" so much
And it would be nice if people got a bonus check from the government just for being outstanding citizens, like in Lilliput, but that's not going to happen in this system of things.
Hint: I buy the hardware, it should come with the source code to make it work
That's difficult if your hardware product is essentially a DSP and FPGA on a board little different from the chip
Re: (Score:2)
Now, I don't think anyone asked for the source code of the FPGA. That one is more to be s
Re: (Score:2)
Exactly for what stupid reason the CPU core instruction set are "proprietary and confidential"?
It is the case; see this post on ca65's mailing list [cc65.org]. But I don't know why it is the case because I don't know how to contact Sunplus.
As for the additional sales for Linux users, well, fuck that! Let's don't use that hardware maker then.
Sometimes people don't have the choice not to use that hardware maker. For example, if all makers of one kind of component of home PCs act this way, such as all makers of mobile broadband cards, is one supposed to just not buy and not use that kind of component? Or they might be using donated hardware, such as a birthday/Christmas gift or a charitable in-kind donation to a no
Re: (Score:2)
At Debian, we do care about binary blob firmware without source. We put them in "non-free", and we don't consider it's part of the OS (it wont go in the released CD, etc.).
Does your installer still insist on installing grub onto the memory stick typically used to provide such firmware for your netinstall CDs instead of the hard drive, or can I finally stop cursing under my breath every single time I'm trying to install a DL360 and I forget to remove the memory stick ?
That is perhaps my biggest complaint about Debian, which is to say that it's been a positive experience for the most part.
Re: (Score:2)
I must have installed debian on my eee 901 fifteen times by now, and all with USB sticks and netinstall.
Never have suffered from that. How long ago did you do this?
IIRC there are options towards the end of the install to tell it which drive/partition grub should go on.
Re: (Score:2)
Re:Software / Firmware (Score:4, Informative)
From their site:
"Update: June 7th, 2011 - Several important things to note, the BC-H series H.264 cards do not have at traditional firmware that is loaded. Everything is accessed directly from the driver / user space applications. Secondly, we report sales of each encoder to MPEGLA and pay any necessary patent fees for the sale of each encoder, meaning that any cards purchased from Bluecherry already have the patent protection from MPEGLA for the device level encoder."
So, in this case the discussion is moot - this card doesn't need any shady things to run on my computer - i am getting one!
Re: (Score:2)
Re: (Score:1)
When the kernel is updated, it's nice to be able to fix the driver.
Re: (Score:2)
Read the update:
Update: June 7th, 2011 - Several important things to note, the BC-H series H.264 cards do not have at traditional firmware that is loaded. Everything is accessed directly from the driver / user space applications. Secondly, we report sales of each encoder to MPEGLA and pay any necessary patent fees for the sale of each encoder, meaning that any cards purchased from Bluecherry already have the patent protection from MPEGLA for the device level encoder.
http://www.bluecherrydvr.com/2011/05/multi-input-h-264-linux-supported-encoder-cards/ [bluecherrydvr.com]
Re: (Score:2)
Why is it important that linux drivers have source available but we don't worry so much about seeing the firmware source? Should we be pushing to see firmware source too? Instead should it not matter about seeing driver source? I'd love to hear your perspectives.
Every device in my machine that does anything particularly useful is going to be largely or wholly proprietary. I appreciate it when the hardware (by way of its firmware) can provide an interface to the OS that isn't needlessly complicated (technically or legally) to reimplement for various OSes and platforms. This makes it much easier to get a driver in source form - which in turn makes it a lot easier to carry support for the device up to a new version of the Linux kernel (since Linux doesn't have a stabl
Re:Software / Firmware (Score:4, Interesting)
Why is it important that linux drivers have source available but we don't worry so much about seeing the firmware source? Should we be pushing to see firmware source too? Instead should it not matter about seeing driver source? I'd love to hear your perspectives.
Device A has an open source driver, proprietary guts, and a firmware blob loaded by the driver on boot.
Device B has an open source driver, proprietary guts, and a firmware blob hidden in an immutable ROM on the device that you don't know about.
For some reason, Debian scorns Device A and praises Device B, even if the firmware blob for Device A allows unlimited redistribution. For the most part I like Debian, but that policy is just silly: Device A is the one that has the greater potential for end-user hackability.
Re: (Score:3)
It takes BNC inputs, which is common for security cameras and takes analog SD video.
Hauppauge Colossus (Score:2)
but alas no Linux support (at all.)
patents (Score:4, Informative)
Good show.
But all the open source drivers in the world won't mean diddly squat if the h264 patent pool gets in the way.
Re:patents (Score:5, Informative)
Obviously, since the output is h.246, it'll need to be decoded for use, which does raise the patent issue; but not at the driver level.
It is not "protection money..." (Score:2)
My understanding, from TFPR, is that the card does h.246 encoding onboard(and the manufacturer of the card has paid their protection money to the MPEG LA) so the driver has no h.246 related duties, it just configures the card and collects the encoded output.
It is not "protection money."
It is a royalty.
It is royalty that maxes out at 20 cents per unit after the first 100,000 units you sell each year.
Unless your are producing on an industrial scale, the custom boards you are buildi for the academic and hobbyist market aren't of the slightest interest to the MPEG-LA.
SUMMARY OF AVC/H.264 LICENSE TERMS [mpegla.com]
Interesting freebies there. (Score:2)
Hmmm...
I see how the fees for codec products (in OSes or Apps) could be a problem for open source. The Freebie there only applies to the first hundred thousand units. There's no way to limit the number of units in an open source product.
But in addition there are freebies for services and encoding for broadcast:
- Encoding as a service for a fee pays only if the encoded "title" is 12 minutes or longer. (At first I thought that might be related to YouTube's (former) 10 minute limit but the Wikipedia
Re: (Score:2)
It is not "protection money."
It is a royalty.
What's the difference? It's the old "freedom fighter" vs "terrorist" distinction. The only real difference is in who you ask.
Re: (Score:1)
Re: (Score:2)
How does the patent pool get in the way? The manufacturer of this pays all the relevant royalties to the MPEGLA for the consumers thus there are NO patent issues at all for the end user. But don't let pesky things like those facts get in the way of your rant.
Re: (Score:2)
Again, read the update:
Update: June 7th, 2011 - Several important things to note, the BC-H series H.264 cards do not have at traditional firmware that is loaded. Everything is accessed directly from the driver / user space applications. Secondly, we report sales of each encoder to MPEGLA and pay any necessary patent fees for the sale of each encoder, meaning that any cards purchased from Bluecherry already have the patent protection from MPEGLA for the device level encoder.
http://www.bluecherrydvr.com/2011/05/multi-input-h-264-linux-supported-encoder-cards/ [bluecherrydvr.com]
That said, not every country accept such patents. I know mine doesn't, and its proudly listed in the 301 report [ustr.gov].
The Stig (Score:1)
Re: (Score:1)
Re: (Score:2)
Cable Card (Score:3)
The REAL issue with Linux/FOSS video right now is the total lack of support for Cable Card and Tuning Adapters. Without them, there is no way to make an effective Linux DVR other than just over-the-air recordings. Gone are the days of "cable ready", analog, and in-the-clear digital.
Of course, that is not the fault of Linux, but of the media giants and cable companies who are just terrified of someone sharing/ripping their content.
Re: (Score:2)
Ceton makes a 4-tuner internal CableCard device (already available), and Silicon Dust makes 3-tuner and 6-tuner network attached CableCard devices (available at end of July). Both devices will work under linux. The Ceton will have support in the next version of MythTV, and the Silicon Dust devices are already supported in the current version. The only downside is that they are limited under linux to only recording shows marked "Copy Freely". What this means will vary from cable company to cable company, and
Re: (Score:2)
Cable cards in general are not what they are hyped to be. Many people have been waiting on them longer than some of us have been using alternatives (namely the Hauppauge HD-PVR). PC Cable Card tuners have been somewhat vaporous while you've been able to get older Silicon Dust products and the HD-PVR at places like Frys and Microcenter for quite awhile now.
CC tuners are also completely useless for Satellite cable.
Re: (Score:2)
The point is, they are here now and usable (in at least some circumstances) under linux. If you are in a situation where you CAN use one of these devices, then it works out to be superior to the HD-PVR. With a CableCard device, you pay under $300 for the device up front, you only have to rent one cablecard for about $2-4/month, and it only consumes about 10 watts or less of electricity. This will get you 3-4 tuners. To get 3 tuners with HD-PVRs, your up front cost is going to be more than $500 (maybe $400 w
Re: (Score:2)
> The point is, they are here now and usable (in at least some circumstances)
Really? Do you have one? I had an HD-PVR as soon as it was possible to have one
after it was released. It was released on time and there were no delays in the release
of the product or extreme backorder delays as have been common with Cable Card tuners.
> under linux. If you are in a situation where you CAN use one of these devices, ...probably not.
> then it works out to be superior to the HD-PVR.
The ugly spectre of DRM raise
Re: (Score:2)
> The point is, they are here now and usable (in at least some circumstances)
Really? Do you have one?
No I don't. I've been waiting for the Silicon Dust device (which as I said previously, will be available at the end of July), but the Ceton has been available and usable under Linux for several months now.
The ugly spectre of DRM raises it's ugly head and makes it very unlikely that a Ceton card is going to be as useful in Linux. This DRM causes problems and imposes limitations even with non-Linux solutions.
Like I said, it depends on your situation. In my case, my cable company (not a monopoly here, BTW...we have competing providers) provides everything that I am interested in "Copy Freely" form, which means there are absolutely no restrictions on the recordings (I can keep them forever, send them to anybody
Re: (Score:2)
Of course, in my previous post, I forgot to add the following: You might be confused, because these don't appear to me to be just regular video capture cards. They appear to only work with security cameras. So the CableCard thing is a little off topic.
Re: (Score:2)
> there is no way to make an effective Linux DVR other than just over-the-air recordings ...or an analog recorder that can handle HD.
Such an arrangement works very effectively with Linux and even avoids some of the pitfalls of using the DRM encumbered options.
Re: (Score:3)
An effective Linux DVR is possible. I know it is not ideal, but you can use an HD-PVR in Linux to capture (in 1080i) the output of any device that provides component output. That's what many MythTV users do... rent the cable company box and just capture the output. Like I said, not ideal, but it is possible, and many are doing it.
Marc
Re: (Score:2)
So exactly how is that capturing HD digital video when the cable box only outputs HDMI?
And how does that work around HDMI security?
And how does that give the computer the ability to tune to a channel?
SD so boring (Score:2)
SD crap is just boring. Wake me up when you can do HD.
Re: (Score:1)
The world is truly better off without H.264
H.264 is actually pretty damned nice. It is patents that the world would be better off without.
Re: (Score:3)
Re: (Score:2)
Well, my 1080p consumer camera saves directly to H.264 - if your ambition is not higher than that, I'd say it's fine. Sure, if you're going to throw in lots of effects and filters and whatnot it's not ideal but two rounds of loss, one in acquisition and one in final print is not that horrible. It's not much point using a worse lossy codec, and if you go lossless those 3TB will be gone rather quickly...
Re: (Score:3)
Re: (Score:1)
The thing that makes H.264 bad for editing is not that it is lossy, it is the interframe compression.
You do realize that almost none of the formats used as intermediates are lossless, right? ProRes, DNxHD, etc are all lossy as well. Secondly, you can encode H.264 as intraframe only and still get better compression ratios than most of the other competing intermediate formats and you can easily edit it. You post smacks of knowing absolutely jack and shit about what you are talking about.
Re: (Score:2)
but it sucks rabid weasel scrotums for acquisition and editing.
How so? H.264 intraframe for doing editing and for an intermediate is pretty darn awesome. Using something like x264 with a pretty decently low CRF value you can beat pretty much any of the "pro" codecs for the same work. And it's funny you whine about the "horsepower" but most of those other intermediate codecs are usually just as intensive if not more so than working with H.264 (which in most cases you are using a hardware accelerated solution so it's all moot anyway).
Re: (Score:1)
I would not say world would be better without patents.
I would say world would be better with reasonable time with patents. Like you have 2-3 years time to start commercial use with the patent or loose it. From the patent day (day 1) you have 5 years to use it, if you got commercial use for it. And then it comes free (not public domain but something like GPL).
Without patents you would not have copyright either and so on no GPL or any other license than just public domain and that means there are no protectin
Re: (Score:2)
Without patents you would not have copyright either and so on no GPL or any other license than just public domain
BULLSHIT
Patents and copyrights are very different and there is no reason you can't have one without the other. Software has been copyrighted for far longer than it has been patented. In particular copyrights protect a particular implementation of a method but there is nothing to stop someone else implementing the idea themselves. Patents protect the method itself which can mean there is no way to implement a standard format without giving into the patent holders demands (which are often incompatible with th
Re: (Score:2)
Actually....patents are supposed to protect only a particular implementation of an idea. Software patents have expanded to the point where they are encompassing the idea itself and that is the problem.
Re: (Score:3)
The world is truly better off without H.264
Why? It's a good codec as demonstrated by its wide adoption.
Re: (Score:2)
The world is truly better off without H.264
Why? It's a good codec as demonstrated by its wide adoption.
The geek can be entirely self-absorbed, seeing nothing beyond his own pre-occupation with computers and the Interenet.
But standards like can H.264 evolve and take root in very different environments. They can serve very different constituencies --- and when they gain traction on the web, they can take him by surprise.