libuvc can be used to capture from these devices:
You can get cheap off-brand UVC USB grabbers, or you can get higher quality gear, like the AJA U-TAP:
Admittedly though I haven't seen anything that comes close to £45 :-)
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 -- and if you need more you can drop down into C or
Python, though admittedly the learning curve is fairly high.
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.
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
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.
Here's a device that looks a lot like the Magewell USB 3 UVC HDMI grabber for $118 (with free shipping):
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.
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.
However our reliability requirements may be different than yours & the OP's, as
we (at http://stb-tester.com ) use video capture for automated UI testing so we
need rock-solid reliability.
I concur with the other commenter that devices with an upstream driver --such
as the UVC driver-- are the way to go.
I've personally seen 4 red rockets die. considering the price at the time, for what was basically a glorified jpeg2000 decoder, it was bollocks.
Could you recommend a Blackmagic product supported by your plugin that can capture from HDMI (cheaper the better, I plan to use it for hobbist-level capture of desktop/games)?
Apart from possibly needing an update to the kernel package, all of the DeckLink devices are supported by the same SDK, with only some small variations (like giving the user the choice of selecting which input connector to use or similar).
I used the Intensity Shuttle for USB 3.0 on a Macbook (OS X) to develop the plugin. It costs $190 and works pretty well, but can't capture 1080p @ 60fps (only 720p/1080i). I only got it because I couldn't install a PCI-e card on my laptop ;)
If you need 1080p @ 60fps, the Intensity Pro 4K is also $190 and is a PCI-e card. Otherwise, the Mini Recorder should work just fine.
If used as intended will it allow an HDCP source to show on a non-HDCP display? Because stupid AppleTV won't allow "protected" content to display on mt main TV because it doesn't support HDCP, and if you buy something on iTunes you don't find out until you've already purchased it. DRM is driving me away from services like that and I'd rather just stop using them than buy another TV.
Hard to beat for the price, though
I am confused by this ... HDMI is a digital interconnect and deals in digital I/O ... in my mind, if you succeed in capturing that HDMI, the resulting stream should be identical ... why would there be a quality (or any other) difference ?
The screenshot in the video suggests 1000fps but that figure is highly dubious. It is much more likely to be 30 or 60fps on a cheap HDMI->IP converter like this.
Also, 1920x1080x60x24 is just under 3Gbps; where are you getting 4.46?
And even if you wanted to record compressed video, you'd almost certainly get better quality feeding it through other HW encoders if you didn't want to spend CPU time on it.
I read it can be containerized as an MKV, but then would you re-encode as H.264, or is there a better codec?
I assume there is a quality vs time to encode trade-off?
Also, would this be a component in a viable DIY HDMI matrix switch?
I see this 4 input / 8 output 4K HDMI matrix switch for only $169 on Amazon here: http://amzn.to/28Ykyor
So, cost-wise not viable, but I like the idea of having more programmatic control of the switch.
I had not considered using a raspberry pi on the receiving end.
Any thoughts on using multiple Pis to receive the same stream?
I would like to take the output from an HDMI source and display it on multiple displays throughout my house.
Realtime encoding is within the reach of some schemes on some processors.
Can you elaborate on that?
What sort of setup (hw/sw) would one need to make this viable (realtime encoding from the stream)?
P.S. See also https://trac.ffmpeg.org/wiki/HWAccelIntro
The method in the link gives you the raw HDMI stream, which you can containerize to play in VLC and the like, but you wind up with some pretty large files.
You could potentially be capturing a raw 4 to 18 Gbps stream.
[Edit: Added MJPEG, as this seems to be case for the device in the article]
Unlike a lot of such devices this one is stand-alone, I don't plug it into a PC, I just use it as an HDMI pass-through, plug a USB3 external hard-drive into it (it also has a bay for internal 2.5 SATA HDD, but I use an external drive so I can just pull that out of the capture device, plug it into a computer to get the captured mp4 files over quickly and easily for editing).
The stand-aloneness of this device is pretty great because it means you don't need to muck around with drivers on your other computers, though YMMV depending upon specific usage, a lot of people like to do live streams directly to places like twitch and this device isn't really well suited for that sort of thing.
Also, this device (AFAIK) doesn't do HDCP pass through. Game systems generally don't enable HDCP during gaming (but do during, say, blu-ray playback). So that certainly makes it less flexible than solutions which will allow HDCP capture.
For what I'm using it for, latency doesn't matter much. I'd estimate it has about 1.5-2 seconds of latency, but I've never actually measured it.
The afaik best app for doing this is Duet Display , if you want to use Mac/Win. But I want to use it for a Raspberry Pi for example. Duet display streams the display information to the own application via ethernet over lightning port.
HDMI itself is also some network protocol (dangerous superficial knowledge). Theoretically it should be possible to build a small device, which translates hdmi video/audio to the same kind of network via lightning port as duet and display?
What do you think? Do you see any pitfalls there, which I don't see?
This could be a rather major caveat to this solution if it only works on unencrypted sources.
A. Well, Duh!
B. Well played reverse engineering Sir!
C. Oh no, I need to do better next time!
D. I hope management doesn't see this...
"[...] by default it will output matroska, aka mkv with both video and audio so that it can be easily interfaced with (no compression happens in this stage, just containerisation).
new version producing ordinary h264, can stream directly to YT/twitch