Forgot your password?
typodupeerror
GNU is Not Unix Input Devices Graphics Open Source Software Hardware

GPL'd Driver and Linux Support For New H.264 Capture Card 119

Posted by timothy
from the to-those-who-wait dept.
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."
This discussion has been archived. No new comments can be posted.

GPL'd Driver and Linux Support For New H.264 Capture Card

Comments Filter:
  • by dintech (998802) on Tuesday June 07, 2011 @04:09AM (#36360188)

    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.

    • by Anonymous Coward

      Firmware is on the device, the drivers are on my computer.

      • by wvmarle (1070040) on Tuesday June 07, 2011 @04:24AM (#36360256)

        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.

        • by sirsnork (530512)

          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?

          • by wvmarle (1070040) on Tuesday June 07, 2011 @05:09AM (#36360404)

            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.

            • by tempmpi (233132) on Tuesday June 07, 2011 @05:29AM (#36360466)

              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.

              • by hairyfeet (841228)

                I'm sure I'll probably get hate for pointing this out, but it is also why you can get card X for cheaper than card Y, just as with Win 7 Starter (which is actually a damned nice low resource OS and I wish they'd sell it as an OEM) through Ultimate having the same code just with different parts turned off. This lets the manufacturers sell the same device with different feature sets thus making it so those of us who don't need Y-Z can only pay for X.

                For an example on the hardware side the AMD HD4830 and HD485

                • by tepples (727027)

                  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?

                  • by Machtyn (759119)
                    From the dumpster - they snagged an old box with an XP license!
                    YMMV, legality not tested.
                    • by hairyfeet (841228)

                      Legal Shmegal, the bigger question is...does anybody care? The Indian working the phone for MSFT does he care? he don't care he just wants to get you off the phone ASAP to keep his metrics high, which is why I have NEVER had a problem activating Windows. Does MSFT care? not according to Ballmer, which I'm sorry I can't find a transcript but I saw an interview shortly after he became CEO where he said "I don't care about the kid that puts a pirated copy of XP on his PC. What I DO care about is that boatload

                • by Hatta (162192)

                  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.

                  • by wvmarle (1070040)
                    What is good (i.e. increases profit) for the producer is not necessarily good for the consumer. And likely, as another poster pointed out, it has also to do with small defects in the chips, just like AMD and Intel are testing processors and then selling them at different clock speeds dependent on what that individual processor can do.
                  • 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.

        • by Hatta (162192)

          Will non-free firmware taint the kernel?

      • Re: (Score:3, Interesting)

        by a10_es (579819)
        how can you be sure it has a firmware?
        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?
    • by Nursie (632944) on Tuesday June 07, 2011 @04:25AM (#36360264)

      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.

      • by Sycraft-fu (314770) on Tuesday June 07, 2011 @05:21AM (#36360442)

        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.

        • by shentino (1139071)

          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.

        • by Nursie (632944)

          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"

          • by X0563511 (793323)

            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.

        • by wvmarle (1070040)

          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.

          • by Tetsujin (103070)

            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?

        • by tlhIngan (30335)

          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

    • 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.

    • by sjames (1099)

      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,

    • by GPLHost-Thomas (1330431) on Tuesday June 07, 2011 @05:18AM (#36360432)
      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.).
      • by mwvdlee (775178)

        AFAIK, Windows isn't released with any firmware on the release CD either.

        • by GPLHost-Thomas (1330431) on Tuesday June 07, 2011 @05:42AM (#36360484)
          And how exactly do you think they provide drivers for Broadcom NICs?
        • by _Shad0w_ (127912)

          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.

        • 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.

      • by tepples (727027)
        So what do you do if you have binary firmware and source, but no free compiler exists for the specific CPU architecture used on the peripheral's microcontroller?
        • 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

          • 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

            • Exactly for what stupid reason the CPU core instruction set are "proprietary and confidential"? The point that VortexCortex is making is that it is for the wrong reasons. The reality is that the vendor is ok to have you locked-in with whatever type of usage they feel happy with. The confidentiality is just bullshit. As for the additional sales for Linux users, well, fuck that! Let's don't use that hardware maker then.

              Now, I don't think anyone asked for the source code of the FPGA. That one is more to be s
              • by tepples (727027)

                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

      • by discord5 (798235)

        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.

        • by Nursie (632944)

          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.

        • This was a bug that was present in the installer BEFORE the release of Squeeze. It's long gone...
    • by Anonymous Coward on Tuesday June 07, 2011 @07:24AM (#36360754)

      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!

    • by Vuojo (1547799)
      From the 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.
    • by AvitarX (172628)

      When the kernel is updated, it's nice to be able to fix the driver.

    • by Artemis3 (85734)

      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]

    • by Tetsujin (103070)

      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

    • by CTachyon (412849) <chronosNO@SPAMchronos-tachyon.net> on Tuesday June 07, 2011 @02:28PM (#36365462) Homepage

      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.

  • patents (Score:4, Informative)

    by shentino (1139071) on Tuesday June 07, 2011 @06:27AM (#36360572)

    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)

      by fuzzyfuzzyfungus (1223518) on Tuesday June 07, 2011 @06:47AM (#36360610) Journal
      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.

      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.
      • 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]

        • 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

        • by Hatta (162192)

          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.

    • by subk (551165)
      RTFA so you won't sound like you know diddly squat. They even put that part in bold for the "TL:DR" types.
    • 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.

    • by Artemis3 (85734)

      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].

  • I bet this driver runs like a 600bhp V8 being that it's made by The Stig [wikipedia.org].
  • by markdavis (642305) on Tuesday June 07, 2011 @07:32AM (#36360776)

    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.

    • 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

      • by jedidiah (1196)

        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.

        • 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

          • by jedidiah (1196)

            > 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,
            > then it works out to be superior to the HD-PVR. ...probably not.

            The ugly spectre of DRM raise

            • > 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

    • 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.

    • by jedidiah (1196)

      > 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.

    • by mrand (147739)

      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

  • SD crap is just boring. Wake me up when you can do HD.

What this country needs is a dime that will buy a good five-cent bagel.

Working...