Slashdot Mirror
GPL'd Driver and Linux Support For New H.264 Capture Card
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."
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.
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.
It's OK for a final distribution codec as long as you have the horsepower to decode it, but it sucks rabid weasel scrotums for acquisition and editing. With common hard drives at 3 TB, ubiquitous gigabit ethernet on LANs, and incredibly fast internal and external bus speeds, there's simply no reason to use an interframe codec or high compression ratios for anything but web delivery.
Nothing worthwhile ever happens before noon
It takes BNC inputs, which is common for security cameras and takes analog SD video.
The world is truly better off without H.264
Why? It's a good codec as demonstrated by its wide adoption.
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.
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.
The thing that makes H.264 bad for editing is not that it is lossy, it is the interframe compression. DV cameras use a variant of MJPEG, where each frame uses JPEG-like compression, but is compressed independently. This means that you can slice the video between any pair of frames without reencoding. If your source is H.264, then it has bidirectional interframe compression, meaning that every frame between key frames depends on the contents of the frames before and after it. If you slice the video anywhere other than a keyframe, you must reencode the frames before and after, which degrades the quality. It takes about 10GB/hour for SD with DV compression, but if you're doing anything more complex than just putting the entire clip on YouTube it's probably worth it.
I am TheRaven on Soylent News