Grabbers for HyperHDR. Part 2: Ezcap 320 USB3.1 capture device

I was excited when I learned about that new product from Ezcap company (thanks @AmbiMod) and I purchased it immediately. Paid around $85 on Aliexpress. I know it was supposed to support Windows only and offers new video encoding that I've already prepared for him in HyperHDR v14 (NV12, xRGB).



OK, after few weeks of testing how to summarize it?
- It offers 4k30 capture for Windows which we don't need it for our ambilight system...but it's fast.
- It supports Rpi4 but max. resolution is 1280x720 and despite NV12 there are visible JPEG artifacts from some internal MJPEG transformation....but it's fast.
- It supports some type of HDR to SDR tone mapping but it's low quality unfortunately...on the other hand it's fast.
- It offers NO contrast, brightness, hue control...but it's fast.
- It's really fast. Did I mention that already? ...and has nice RGB backlit.
- EDIT: just noticed: no support for HDCP AMD 4650G -> HDCP protection error displayed, but Ezcap 269 works... sound: no bitstream (Dolby, DTS) pass-through ...minimal refresh rate is 50Hz vs 23Hz for Ezcap 269 so 4K is useless for movies ...TOTALLY DISQUALIFIED!!!
Seems that I received early version of that device with a buggy firmware. Next firmware upgrades following the official guide didn't help: only firmware number was changing. But there is special, full upgrade procedure (and a bit dangerous) that fix the missing lower refresh rates in 4K and at least DTS bitstream is now available.

As you can see it's a bag of mixed feelings and beside really fast speed I feel like Ezcap 320 is a kind of downgrade from Ezcap 269. At least for our ambilight systems. Some things you can correct with LUT table that I prepared for him and uploaded on the HyperHDR release page but for other software you are on your own.

I don't expect that Ezcap will release new firmware that will fix these issues. For the previous Ezcap 269 they only released one firmware without any change-log so we even don't know if they changed something or it's just original firmware.

What we've got here?
First take a look at our reference screens that were captured by the ezcap 320 in HDR10 mode. Disclaimer: I don't expect 1:1 capture because the HDR is applied. But some rules must be preserved. And now we can see it's some kind of pseudo HDR to SDR tone mapping that is sufficient maybe for recording game sessions.

blue-320 cyan-320 green-320

red-320 violet-320 yellow-320

You must analysis these screens by taking their RGB values. Maybe it may be not seen on some poor quality LCD but we have 3 problems:
- Yellow is greenish, on TV yellow is yellow
- Main problem: blue on TV is blue but here it's violet, especially visible on the LED strip. Why? Because blue component of RGB led has the least saturation. And when to the pure blue (at not even at full scale on ezcap 320) then you add red at 25% scale then you have almost violet. Very unpleasant feeling because you will never see correct effect for the blue sky again and human eye is especially sensitive for that.
- Green has a boost from red and some of blue. Green has the most luminescence of RGB and here Ezcap 320 boosts it further? It causes that the green is a lot more brighter on the LED strip then red or blue.

For other main color-mix you will loose a lot of saturation  but let say it's acceptable. Like I said I've prepared a LUT table to correct that to some extend but dark scenes still remains a problem due to poor calibration of the Ezcap 320's pseudo-algorithm.

Device info:

Windows (HyperHDR v14)



Linux (Rpi4/Raspbian)

linux1 linux2


Is it worth? For that price its questionable. Ezcap 320 is really fast and along with the optimized video processing from HyperHDR the effect on the LED strip is almost simultaneously with TV. But it has also some drawbacks for ambilight users and I won't keep my fingers crossed that Ezcap will do something about it. EDIT: seems they fixed that :)


totopol said…
I'm planning to build an Ambilight by my own but I'm still not sure what kind of grabber should I choose. I usually use Fire TV 4K Stick or Google Chromecast 2nd Gen to play movies. All video signals (including CableTV) go through my AVR to FullHD TV with HDMI cable. You mentioned some time before that there might be some problems with HDCP protocol so there is my question, will a grabber with MS2109 work, will there be any noise or disruption on TV?
The second question is, will it all work with Raspberry Pi Zero? I have RasPi 4, but would like to use the smaller one.
awawa said…
Don't have any experience with Fire Stick or Google Chromecast. Simply tested it with Renoir APU that has HDCP 2.2 and Ezcap 320 failed (fortunately AMD allows to disable it). Ezcap 269 worked with HDCP 2.2 but don't know if it simply removed that protection or doesn't support it so player/graphic card fallback to no protection. Also you can't put Ezcap 320 before AVR because you will lose sound bitstream. And lack of 23/24Hz refresh rate disqualifies it for 4k movie content so I use it for 1080p. For MS2109 you have to have a good and reliable HDMI splitter anyway or atleast dual output from the player or AVR.
I would go with RasPi 4: lack of multi-threading in RPi Zero is a serious downside. There are many small and multi-core alternatives based on Arm but they are no officially supported and you must compile HyperHDR on your own ( ). From version 15 its quite easy.
awawa said…
For example Banana Pi Zero - Allwiner H2+ 512MB RAM
totopol said…
Thank you for quick replay.
I found some cheaper alternatives on Aliexpress. Do you know if they will work? As I mentioned before, I don't use resolution higher than 1080p :
awawa said…
I've got Rullz navi in my testbed, similar to products from your first link. No HDR passthru and only one capture resolution to choose (for example only 1080p, no lower resolution so Rpi Zero can't handle it). I think it's better to pay a bit more for Ezcap 321 (~50$): no HDR pass-thru either but it's much more faster, has bitstream support and allows lower resolution. Still old Ezcap 269 is better and more universal solution, but the price is around 70$ and since you don't need 4k maybe it's not worth extra money.
Unknown said…
Thank you for you work on HyperHDR, this is much appreciated.
Hope you can help me.
I have RPi1B and now also RPi4. I have ambilight working on Pi1 with a small custom made board directly sitting on GPIO pins. For the life of me I cannot remember what is on the board it's been so long, probably voltage converter. LED I'm using is WS2801. All that works fine with standard hyperion. So setup has no USB grabber, I'm guessing it uses internal grabber.
Now I moved to RRPi4 with LibreElec, attached the board to GPI and it does not work, neither with hyperion, nor hyperionhdr.
Rainbow swirl works however, so I'm guessing problems with internal grabber.
My questions are
- can RPi4 work without external USB grabber, I'm trying to cut the costs here and avoid unexpected expenses
This issue indicates internal grabber is not supported on hyperionng
I'm guessing this does not affect hyperionhdr
- if that is supported on hyperionhdr, how to enable it?
awawa said…
Hi Daniel

One of HyperHDR's goals and the main difference from Hyperion NG is to focus and optimize capturing technique using USB grabbers. All the internal grabbers were abandon when the fork was created, because they are problematic and there are even more problems on the horizon: the main cause is DRM. Other problem is video acceleration that can be disabled or interfered by the software capturing and in my opinion it can not be accepted. I think your problems with new Kodi arise from these things.

Maybe it can be solved by the programmers but frankly Dispmanx for Rpi4 is broken for years.

In HyperHDR you can use only USB grabbers or incoming network stream from the client. If your player or AVR doesn't have dual output then it complicates things a bit and generates additional costs because you need a splitter ($50 if new Kodi can output HDR, otherwise around $20) and a grabber (~$10).

Unknown said…
Thanks Awawa, this is very useful.
I went into rabbit hole a bit by upgrading from Pi1 to Pi4 then, was expecting smooth transition with support for h265.
I only use ambilight for Kodi played on Pi, so I don't think I will need a splitter.
It is a bit strange to loop back signal from Pi's HDMI back to it's USB but I guess that's unavoidable. DO I understand all that correctly?
Also, is Ezcap 269 still the best choice considering my use case?
awawa said…
Yes, the signal needs to be loop back to the USB again. Mostly thanks to DRM that prevents software capturing (at least in easy and transparent way). So here it goes the hardware solution as most of USB grabbers can handle it. Some HDMI splitter can even remove HDCP but I doubt you will be using for example netflix player directly so it is not your concern.

With single HDMI from your Rpi4 you need a splitter to provide a signal to the grabber and a second line to the TV. Or to use a grabber with a loop like Ezcap 269. Grabbers with a loop are generally more problematic but Ezcap 269 is proven solution.

If you don't need 4k and you are OK with PCM instead of bitstream audio then perhaps Ezcap 320 could be better but more expensive device.
Unknown said…
Ezcap 269 seems to be difficult to get. AliExpress seems to have it but the price 75 euros which seems to be quite high. Do you think there are other capable capturers. I suppose if we discarded 4k and HDR any of them would do?
From your previous posts (very informative, thank you) is seems that framerate can be wrongly advertised. Also sounds like YUV is important, as is USB3 (again can be wrongly advertised).
awawa said…
I see 75$ on Ali, just a bit higher then I bought it some time ago but I used coupon to reduce a price. Anyway can't recommend any other grabber with a loop because I didn't test them or they didnt't work well like Rullz Navy U3. With such grabbers there is a big risk that they can't pass-through HDR... or sound. Or they don't support some resolution or refresh mode. The only other way I see is good splitter (Feintech 40euro) + MS2109.
Psi said…
Hi which is better, Ezcap 269 or 320? Also what is the lagg of these devices? I've tried some with 100ms lagg but found it too distracting.

Thanks :)
awawa said…
Ezcap 320 is definitely faster but had so many issues with my sample (and still have some) that makes I honestly can't recommend it. With my LG C9 reaction from LED strip is ahead of TV picture by few ms.
BaXxter said…
Hi, everyone,
I hope someone can help me with a problem with an EzCap320 grabber.

I use an AppleTV 4k (2nd Gen) (4K, 60fps, HDR, HDCP 2.2) as the HDMI source. The signal goes to a FeinTechHDMI splitter (VSP 01201) and is forwarded by this with HDCP 2.2 in 4K to my LG-oled and in parallel in 1080p and with HDCP 1.4 to my grabber (currently still lightbarry analog grabber).

With HDCP I had no problems so far in the constellation (Feintech splitter working well).

Since I have color problems with HDR, I wanted to switch to the EzCap320.
I replace the lghtberry analog grabber with this one and start the grabber software on a Windows computer, this also works. I can play HDCP encrypted 4K HDR films and the grabber software shows them to me.

I can't get the EzCap to work on my Raspberry Pi 4 with HyperHDR v11 (SD installation).
At first the hardware could only be selected if I took a USB 2.0 instead of 3.0. But there was never a picture but a black picture where an HDCP problem is pointed out. I updated the grabber firmware and after that the hardware was still recognized via USB 3.0 and no longer 2.0. From then on, higher resolutions could be selected than before the update. but still a picture. only HDCP error message in the grabber image ( in all possible combinations of formats ).
Since a picture arrives via PC, HDCP is not the problem.

Does anyone have an idea here?
I've already tried dozens of different HDMI splitters to get rid of the HDCP 1.4 in 1080p, but no change either.

i am at the end of my ideas
awawa said…
The host (Windows or Rpi) to which ezcap is connected by USB or the software capture application doesn't influence HDCP capability because it is handled by the device. Simply, that grabber refuses to handle it. On Windows it's easy to disable it and for some graphic card drivers it's disable on default. But HDCP can be remove in any case with proper HDMI splitter for example Ezcoo after the firmware upgrade
BaXxter said…
Hi ,
many thanks for the answer.
However, I think you misunderstood me, or I expressed myself badly.
Of course I am aware that HDCP takes place on the hardware side and has nothing to do with the host / software connected to the EzCap320.

That's exactly what amazes me.
I already use an HDMI splitter (FeinTech) in my setup that forwards the signal from the AppleTV to the LG and at the same time forwards a signal downgraded to 1080p (thanks to the downgrade even without HDCP 2.2) to the grabber.

If I play exactly the same film on AppleTV and connect the EzCap once to my Windows computer (EzCap software for displaying) and once to my Pi 4 with HyperHDR, I get the movie on the Windows computer and only get the message "HDCP error" on the Pi .

Since my setup does not change and works with Windows and EzCap software, an HDCP problem is impossible. The problem must lie in HyperHDR.
awawa said…
HDCP handling for that grabber is beyond the reach the application. It doesn't even expose such interface. So it's impossible that HyperHDR could cause such behavior ;)
BaXxter said…
I think exactly the same. therefore I do not understand where the problem could be :D it makes no sense that the grabber works on the windows computer and not on the pi
hi, i never see this formart before .3d, can i convert this lut on CUBE or PNG?
awawa said…
Hi, it's internal HyperHDR format. Currently the is no export feature, but 3dl Autodesk LUT can be imported into .3d.
Crypto said…
Hello. I need your help.
I'm having trouble connecting EZCAP 320 to Raspberry Pi3 B+

When connected in Windows, the video signal HDMI passes through EZCAP and goes to the TV.
OSB defines it in the device list. Works with both USB 2.0 and USB 3.0

But when connected via USB to Raspberry Pi3 B+, ​​the video signal does not pass.
In the list of devices by typing "lsusb" into the command line, ezcap is not detected
Raspberry Pi powered via usb Brand new UGREEN 3A 0.5m cable
Do you need to install any additional drivers?

I installed the latest firmware on EZCAP 320 from official website and installed the latest version of PI OS

awawa said…
The latest firmware for EZCAP 320 could break Ezcap 320 compatibility with Linux / Rpi / USB2.0.
Acquire older 320_1_3_8_4_1230 firmware from their support.
Crypto said…
Thank you very much. I'll try to contact them.
Crypto said…
Thanks for your help.
They sent me the firmware version with which my EZCAP320 worked with Raspberry PI3
I posted it in the cloud:

Prompt does not work CEC, as I understand it, you also failed to make it work.

I understand correctly that I additionally need to install Between TV Box and EZCAP320 HDMI Splitter with CEC support
I plan to install this (EZCOO EZ-SP12H2)
Can you tell me if it fits?
My TV BOX is TOX1, TV Hisense U7QF. When connected directly With an HDMI cable, CEC works fine.
awawa said…
The Ezcap 320 does not support CEC pass-through, so it must be eliminated from the path between tvbox and tv using an HDMI splitter. Unfortunately EZCOO EZ-SP12H2 doesn't support CEC either. But higher-end Ezcoo models and for example FeinTech VSP01201 supports CEC (feature introduced probably few years ago, only very old second-hand models may not support it).
Crypto said…
Two days ago I was interested in the issue of CEC operation on the EZCOO EZ-SP12H
Asked a question to their support team and received a response:
Dear Sir
The CEC only available on OUT 1. Please connect the TV to OUT 1.

Tell me, it did not work for you from personal experience or from reviews of other owners?
I'm going to buy today, but I would not want to take something that does not work.
awawa said…
The Amazon product page clearly states that it doesn't support CEC, so someone has to be wrong. Maybe their included CEC support in the latest revision? If you still want to test the EZ-SP12H2, make sure you can return it to the store and get a refund without problems if the splitter does not meet your expectations.
Crypto said…
Thanks for your advice. I'll try to figure out where the truth is.
BaXxter said…
Hello awawa,
I have a problem with an EzCap320 on a RaspberryPi 4 .

My setting : Source is an AppleTV 4K (gen 2).
From here it goes to a FeinTech VSP01201 (in Copy-EDID mode).
From the splitter it goes via HDMI_out1 in 4K HDR (HDCP2.2) to an LG oled and via HDMI_out2 in 1080p (HDCP 1.4) to the EzCap320.

Thanks to the FeinTech splitter, I have a 4k -> 1080p downgrade on HDMI_out2 and no HDCP problems. works here with an old lightberry too.

If I connect the EzCap320 to a RaspberryPi 4 with HyperHDR v18, I can choose different formats via USB2.0 as well as USB3.0 (higher resolutions via 3.0, of course).
However, the screen preview of EzCap320 USB output in HyperHDR always shows me in every possible constellation: "HDCP protection". It shows that even if I set the apple TV to 1080p SDR. So something is wrong with the EzCap320 here.

That's why I plugged the EzCap320 into a Windows PC instead of the Raspberry and opened HyperHDR v18 here. Exactly the same problem AS LONG as I open the EzCapLink software at the same time.
As soon as it starts (I don't click anything, there is only an error that the device is already in use) the EzCap320 seems to activate and I have the desired image.
From this activation by EzCapLink, all selectable formats work and 4K HDR 60fps with HDCP 2.2 is also no problem (as actually expected).

As soon as the EzCap320 is unplugged from the USB and plugged in again, the display shows "HDCP Protection" again until I open EzCapLink again.
On the WindowsPC this is a possibility to get HyperHDR running, but not on the RaspberryPi.

Do you have an idea about this?
is it possible to install activation by starting EzCapLink in HyperHDR?

Why doesn't everyone else using the EzCap320 seem to have this problem?

By the way, I tested with the old EzCap firmware as well as with the newest 1.4.3

Thank you for your help !!
I've already spent so many days with the problem and I'm starting to despair.
awawa said…
Ezcap 320 firmwares gave me a lot of headache in the past, but in this case I would trust that message. Did you rule out the Feintech splitter as a cause of the problem? I recommend you to use Feintech 'mixed mode' instead of 'copy mode'.
awawa said…
And if you flashed Ezcap 320 firmwares did you check the full option? I remember that default option was the partial/incomplete update. The Ezcap update manual was also screw-up in the past, maybe they fixed it now.
BaXxter said…
Thanks for your reply awawa.
Isn't a problem with the FeinTech VSP01201 already ruled out by the fact that you can start video grabbing just by opening the EzCapLink software? Without making any changes to the hardware !
If the VSP were the problem, you shouldn't get a picture with this trick, would you?

I tested the VPS mode from copy to mixed several times, but it made no difference. And the description also states that 4k is only output in copy mode on HDMI1 and 1080p (downgrade) on HDMI2, as is required here in order to get from HDCP2.2 to 1.4 for the EzCAp. In mixed mode, according to the instructions, it should only output 1080p on HDMI1 AND HDMI2 . No more 4k.

I've looked for the "full" option you mentioned, but couldn't find anything in the tool. The instructions were probably adjusted in March 2022, but only to the point that you have to enter the correct PID number.
Initially, this is set to 3200 and I left it that way (since I had used the old instructions). but there is no connection problem, because I get a picture delivered. even if it only says "HDCP Protection".
I am using firmware update tool from here for ezcap320/B
awawa said…
"Entire flash" option before flashing? In the old manual it was "custom area > firmware". HDCP protection touches only the grabber function, it can still be forwarded to the TV through the Ezcap 320, but simply it refuses to capture it.
BaXxter said…
I used the "Entire flash" option for every firmware update (it was also in my old manual from 2019).

I don't use forwarding through the EzCap to the TV, because the VSP on the EzCap only gets 1080p (for HDCP 1.4).
My TV is connected to HDMI1 of the VSP with 4k output (HDP 2.2).

At the HDMI output of the EzCap I have my old lightberry grabber to check if really only 1080p arrives without HDCP2.2, since it then no longer outputs an image.
That always works, since downgrading the VPS seems to work well. EzCap's "HDCP Protection" message must be wrong. I had previously suspected that EzCap is simply locked until you open the software to view EzCap, forcing you to purchase its license.
But then, as already mentioned, it would not work for anyone.
awawa said…
In my initial manual it was stated otherwise (had a screenshot because Ezcap support couldn't believe it too ;) ) and was leading to new problems. And I was referring to that part "but there is no connection problem, because I get a picture delivered. even if it only says "HDCP Protection"" It can delivered even with HDCP protection but the grabber won't work so that test tells won't tells us nothing if it's protected or not. And old grabbers like Ezcap 269 were more tolerant for various HDCP handshakes scenarios (but still not enough to handle Apple TV HDCP2.2).

If you disconnect the grabber when it's working, and then you reconnect it again so "HDCP protection" appears did you disconnect or power off the Feintech or the TV? I have no more ideas and maybe you can contact Ezcap support and share the solution with us if they can have one?
awawa said…
BTW don't know if it's related but I remember there were also problems with Apple TV, Ezcap 320 and popular Ezcoo HDMI splitter. This splitter was capable of HDCP2.2 but Ezcap 320 displayed "HDCP protection" error. The firmware update for the HDMI splitter was necessary so maybe Apple TV HDCP implementation is very strict and causing incompatibilities. You should find details in the Github HyperHDR discussions. Still I've got no explanation why EzCapLink can turn it off by itself using some kind of trick.
Matias said…
@awawa the "HDCP protection" in ezcap 331 is controlled by ca-server.exe ("Cloner Alliance Device Helper service") which gets installed alongside ezcapLink software and runs in background as a service. It listens for compatible devices being connected and does HID USB magic on the device:
Apple Macs are really good at providing HDCP flags, but if the service is running all capture software including OBS doesn't show the HDCP overlay.
awawa said…
@Matias Very interesting. Can it also be used with other grabbers? I remember some old user reports that their ezcap grabber (not 331/320) worked with their video source on windows but stopped working when they connected it to the Rpi. It is possible that they had the manufacturer's software installed on Windows. I will try to investigate it.
Matias said…
I've looked at the binary with IDA and it's checking for older devices too - namely "FHD Webcam", "FHD Capture", "CA Flint", "CA Chert" (VID_048D&PID_93). VID_32ED&PID_32 seems to be the new one. 2C99 (likely PID) is also mentioned, but I'm not sure of the context of the "if's" in the code - the last time I did any assembly was about 20 years ago :)
So I think it might work for older ITE/Sunplus based capture devices.
Matias said…
I just checked with my old USB 3.0 capture device (Wiistar HD Capture) and it's VID_1bcf&PID_2c99 (long time ago I reflashed it with ezcap firmware so it presents itself as a "Sunplus Innovation Technology Inc. ezcap U3 capture"). But I think that for the old capture dongles the service might only be doing the "audio sync fix" which looks like just making sure the audio capture device on windows runs at 48 kHz.
BaXxter said…
I posted a year ago about my setup with EZcap320, feintech VSP01201 and apple TV.
I had problems to get no image with py raspberry pi.
Now I know that the setup is working ( 4K, HDR from apple tv, feintech downgrades it to 1080p HDCP 1.4 for ezcap). I am using it some moths now working perfect, (and very fast ).

It still does not work on my raspberry, but i found an old surface (windows) on which it is running now.
BUT if I start windows and run HyperHDR it first seems to not work (black screen).

I have to close Hyper HDr, open Ezcap link software ( as already mentioned from me and Matis , this starts a background service that unlocks the ezcap capture), then close ezcap link and start hyperHDR one more time. then it works perfect until the next windows restart ( I did not restarted it since months :D ) . so the ezCap 320 hardware is working perfect with hyper hdr. but sadly not on raspberry. I would prefer that more, than running a windows PC permanently. if someone would have an idea how to get the ezcaplink-unlock working on a raspberry I would be very grateful :)