Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can also use devices that are USB Video Class (UVC) compliant, thus which don't require any drivers.

libuvc can be used to capture from these devices: https://github.com/ktossell/libuvc

You can get cheap off-brand UVC USB grabbers, or you can get higher quality gear, like the AJA U-TAP:

https://www.aja.com/en/products/u-tap

Admittedly though I haven't seen anything that comes close to £45 :-)



I second the UVC driver recommendation, or anything with drivers upstream (that is, in the Linux kernel itself). If this is for your day job spending £250 is well worth it for one of the better quality brands, otherwise you'll be spending far more than that debugging reliability issues.

Depending on your project, it might be worthwhile using GStreamer instead of tying yourself to a specific driver like libuvc. There's a lot you can do with just GStreamer's command-line tools -- for some examples see the first 5 minutes of my talk[1] -- and if you need more you can drop down into C or Python, though admittedly the learning curve is fairly high.

[1]: http://www.youtube.com/watch?v=Fdn2LxxM7wA&list=SPSIUOFhnxEi...


I've personally had a great experience with the Magewell USB3 HDMI capture device, which I believe is also UVC - requires no drivers on Windows/Mac and claims to be Linux compatible. Slightly cheaper than the u-tap.

https://www.amazon.com/Magewell-HDMI-USB-Capture-Dongle/dp/B...

Can do lossless capture with extremely low latency, which is pretty nice - it's good enough that I've been able to play console video games on it directly instead of plugging into a TV.


I use the Magewell too and wrote a blog about my search https://natalian.org/2015/03/13/HDMI_in/


It's still about $150 more than just swallowing your pride and using Hauppauge's Windows drivers.


there's a reason the Starts with "cheap".

all solutions so far cost well over what most people paid for their computers or TVs.

there was pro composite capture under 200 for a long time. and cobsumer ones for 30ish. and thats dealing with analog. hdmi without DRM should produce even cheapers devices, but yeah, everyone has to embrace DRM to name it hdmi


The UVC one mentioned looks to be in the ~$400 USD price range, which is a far cry from the $800 stuff the article author looked at, but it's still more expensive than the <$100 solution presented.

Was that $300~$400 worth the time needed to reverse engineer the cheaper solution? It's all about tradeoffs really. At least it's open source so other people can use it now without the time involved. Also if you need to read in from 5 ~ 10 cameras, the cost can grow very quickly.


If you want to save cash you can try your luck on AliExpress.

Here's a device that looks a lot like the Magewell USB 3 UVC HDMI grabber for $118 (with free shipping):

http://www.aliexpress.com/item/Free-Shipping-XI100D-UVC-USB3...


I just bought that device 2 weeks ago... and tried it, but so far haven't gotten any video out of it under Linux or Windows.


They certainly seem a bit confused about what kind of USB 3 connector they are meant to put on their box!


It's not HDMI and DRM increasing the costs. HDMI is a far higher bandwidth signal than composite/SVideo, as is USB3. So you have to design a more complex chip and PCB.

These are slightly more niche products too, so you don't get the economy of scale you would with something like an ARM SoC.

Also these UVC grabber deal in uncompressed video, so they are more expensive but produce a far higher quality capture.

The £45 Cat5 grabber is performing some pretty heavy compression to fit the HD video signal down a 100 Mbit Ethernet connection.


> hdmi without DRM should produce even cheapers devices, but yeah, everyone has to embrace DRM to name it hdmi

Not really. HDMI capture devices actually can't "embrace" DRM; no (legitimate) HDMI capture device is permitted to decode HDCP at all since that would defeat the point of HDCP.

HDMI capture devices are expensive because it really is difficult-- 1080p is a lot of bytes per second to decode, reencode, and record to permanent storage.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: