HyperHDR: prepare for building & buying components, step 3: USB grabber

 Guide for building your own ambient system:

Choosing USB grabber

Extremely important choice. Some solutions you can exclude at beginning: all sort of legacy, old analog grabbers like UTV007.



The market is full of its clones, they are very problematic and offer pathetic video quality from SECAM/PAL/NTSC era. If you decide to choose them then unfortunately you are on your own...even Microsoft abandoned support for them in one of the latest version of Windows 10.

So what to choose? Modern UVC class digital grabbers are the best way as they are supported both under Windows and Linux. I chose Ezcap 269 then upgraded to Ezcap 320 but it has some drawbacks.

 

  • 4K60 HDR support...well, it's not true. Later their changed that marketing slogan to 4K HDR pass-through. Again, it doesn't exactly work that way. When the grabber isn't capturing then pass-through works as advertised. But when it starts to capture 4k then the only color format that worked for me was RGB. YUV 420 is causing troubles. So it isn't completely neutral pass-through. 
  • It doesn't capture properly HDR content that's why you will need HyperHDR to fix it.
  • Supports both YUV (USB3.0) & MJPEG for 1080p 60FPS capturing 
  • USB 3.0

Sounds not to optimistic? Don't worry because it would fit our needs for high quality 4K & HDR capable ambient system. Other hardware solution are even worse (at least below $100 budget).

It's important that it supports YUV encoding. It provides better quality than MJPEG and MJPEG requires more CPU resources to decode it.

YUV encoding is available only when you connect it to the USB3.0 port as it requires more bandwidth than MJPEG.

When you connect it to the USB 2.0 port MJPEG encoding is the only available option:


 
 

What's the alternative? For example MacroSilicon MS2109 clones:


 

It has a very nice price and lag around 100ms. It's supports YUV and MJPEG (for higher FPS modes).

Read more: Short test of black Rullz MS2109 USB 2.0

There is also "USB 3.0" model that can capture 1080p/60fps:

You see that blue USB connector? It's USB 3.0 for sure...no, it is not. It's just ordinary USB 2.0 plug painted in blue color. 

It supports only MJPEG encoding. USB 2.0 would be insufficient for 1080p/60 capturing for YUV.

Currently I'm using Ezcap 320: it has some kind of automatic HDR tone mapping that can be corrected with my custom LUT table available in the download section on github. But I was forced to abandon 4k and to bypass sound using another route.


Read more: Ezcap 320 review


Comments

Unknown said…
Will the easycap 269 work with the nvidia shield (2019) in 4k HDR? So far I've been holding off continuing my hyperion project (started when I had an ordinary 1080 TV but never finished).
awawa said…
Sorry, been busy with just release version 14 of HyperHDR ;) Unfortunately didn't test it. Probably the problem is in the ezcap 269 and new version of nvidia shield can change nothing. But it can be workaround with FeinTech VSP01201. Then NVidia shield is independent from any grabber (but it's one device more in your setup...).
saml said…
Hey thanks so much for this fork and this blog! I've been working hard to try to find a solution for when I get a PS5 (whenever they come back in stock) so I can play it in 4K@60hz.

I have a few quick questions. Will the MacroSilicon MS2109 clones work well for 60hz with this splitter?
https://www.amazon.com/Splitter-avedio-links-HDMI2-0b-3840x2160/dp/B07XCZC6SP/ref=sr_1_3?dchild=1&keywords=4K%4060Hz+HDMI+Splitter%2C+avedio+links+HDMI+Splitter&qid=1609560781&s=electronics&sr=1-3

The splitter you recommend later on isn't available in the states and I don't quite have the budget for the ezcap 269.
awawa said…
Hi
4K@60hz is not supported by that splitter for down-scaling to 1080p, so first problem. Next could be that MS2109 does not support 1080p/60 properly so it need to be downscale even lower. Dont know if that splitter can do it. BTW even Ezcap 269 is problematic for 4k, HDR is works only for RGB, without HDR it should works for other color space too. There is new Ezcap 320 that I'm testing and it looks good but it's even more expensive.
saml said…
What about this capture card with pass-through? It says it can take in a 4K@60hz signal and loop it out while capturing the picture at 1080p/60.

https://www.aliexpress.com/item/1005001526129063.html?spm=a2g0s.8937460.0.0.45c12e0ef8NkWS

Also would this all work with a Raspberry Pi 3b+? That's the newest one I have and I know it doesn't support USB 3.0, but was hoping it'd work anyways. I could upgrade to a Raspberry Pi 4 if I have to though.
awawa said…
@saml I've got Navy USB 3.0 U3.
- with USB 3.0 it produces YUYV stream, with USB 2.0 (Rpi3): MJPEG.
- you can't choose resolution: it's only one chosen automatically(1080p or 720p)
- you can choose framerate: 60/30 fps
- it can't pass-through HDR signal

For $25 I paid it's OK, but I would stay on cheap MS2109 or pay more for Ezcap 269. There is no good solution in the middle unfortunately.
awawa said…
Hi
In short.

ms2109 advantages:
+ cheap
+ fast
+ works great with USB 2.0 (for example Rpi3)
+ better MJPEG encoding quality than ezcap 269
+/- has YUV encoding which is better than MJPEG but it's available only for lower resolution

ms2109 disadvantages:
- Doesn't have a loop like ezcap 269, so an expensive HDMI splitter may be necessary
- Depends on the source its quality can be lower or higher. Sometimes they even remove internal radiator to reduce a price...

ezcap 269 advantages:
+ Has a high performance 18Gb loop that can pass-through HDR so you don't need an expensive additional HDMI splitter
+ Offers excellent quality and low lag for YUV but USB3.0 is necessary (Rpi4 or Windows PC)
+ Good quality and reliability

ezcap 269 disadvantages:
- on USB 2.0 it offers only MJPEG, it has worse quality then ms2109 but it can be overcome by using higher resolution, for example 1280x720.

I used ezcap 269 with Rpi3 for a very long time I can't complain. I would stick to it if you have already purchased it.
flens74 said…
Hey HyperHDR,
i want to buy a Ambi Kit and my first opinion was to buy a RPI3 with Feintech-1201 Splitter and USB Grabber (UTF007). Now i have read your Article about the Ezcap 269.

So which do you prefer:
RPI3+ Feintech Splitter 1201 + USB Grabber
or
RPI4 + Ezcap 269

For both i want to use with ESP8622 and WLED + SK6812

question is because i hear that RPI4 isnt that stable an causes more problems then RPI3

thanks in advance
awawa said…
First rule that you already should know is: stay away from UTF007 ;) MS2109 is a good replacement.

Ezcap 269 can be problematic for some color's encoding in 4k: yuv 444,422,420, only 8-bit RGB but is somehow reliable. Otherwise for 4k RGB and for 1080p capturing is quite good. And it handles HDCP well so if you are using a player that requires it (netflix, firestick) then it's good choice. I never tested if Feintech Splitter 1201 is capable to strip HDCP 2.2 protection (probably no). There is also new Ezcap 320 that you can read about it on my blog but it was two major drawback: price and no support for HDCP. But it handles HDR tone mapping a bit better, is fast and has no problem with colors encoding and supports even 4k120.

Hard choice..it's depends what you need (resolution/hdr/speed et).

I read years ago about problems with RPI4 and SPI: I've got RPi4 for some time and I used it also for WS2801 with no problems at all. Definitely Rpi4 is a way to go as Rpi3 and Rpi4 are in the same price range now. You need to have reliable power supply in both cases. Earlier Rpi4 version may be more picky about USB-C power supply...if you buy it on Aliexpress probably then you could get that old version probably. I've got old version too but with the genuine power supply so have no problem.
nocturno said…
Hi, Im using a RPI 4 with MS2109 capturing MJPEG at 1280x720 30fps but recently I bought a Ezcap 269 hoping to get better results but I can't see the difference, in fact I think the MS2109 looks much better.The Ezcap is capturing YUV ar 1920x1080 30fps. I was looking for the specific lut for the Ezcap 269 but I only find the 320 one. can someone share the link for this out file and post the settings in hyperhdr for this device, maybe I'm missing something. Thank You!
awawa said…
Default LUT is to correct images that was captured as SDR from HDR (in fact it makes HDR from SDR again). It doesn't affect quality. Ezcap has a loop with a support of HDR and HDCP that MS2109 doesn't have. MS2109 has much better quality that EZcap in MJPEG and i mentioned that in the review. For YUV I didn't notice much difference but beside better quality yuv has a task to lower CPU usage on Rpi and MS2109 can't provide it. Ezcap 320 provides loss-less stream (XRGB) but that mode is not available for Rpi4 and has some other drawbacks that I mention in the latest review. LUT table for ezcap 320 is specific because ezcap 320 does some sort of tone mapping and LUT table is to correct it to some extend.
nocturno said…
That mean the default lut should work with the Ezcap 269? If I don't need the pass-through option is there any other big advantage on the RPI4 over the MS2109 or I should return it? sorry for posting this on git i though the other post never go through. Thanks
awawa said…
If the lowest lag is not a priority and you don't need a pass-through then Ezcap has a little advantages over MS2109. Didn't tested if MS2109 is capable of by-passing HDCP2.2 that is required by some secure video players (ezcap can do it).
nocturno said…
I have it connected through this splitter https://smile.amazon.com/gp/product/B07ZNKF7C8/ref=ppx_yo_dt_b_asin_title_o09_s01?ie=UTF8&psc=1 and at the moment Im not experiencing any lag. Im playing right now with your HyperSerialWLED_ESP32DEV_firmware having some trouble everything appears ok in the logs but the light is very erratic. It works if connected through the network but im going to reinforce some solder points to see how it goes. Im learning a lot. Thank you
awawa said…
I meant that decoding MJPEG takes some miliseconds more then YUV, maybe it's not a big lag but still it's there. Erratic lights with HyperSerialWLED indicates: problem with a transmission (transmission errors, configuration problems: speed is not 2000000, non-active awa option in HyperHDR), interference of WLED core for serial processing et. HyperSerialESP8266 has some debug message but I didn't implemented it for HyperSerialWLED yet.
nocturno said…
2021-01-19T23:46:55.844Z [hyperiond LEDDEVICE] (INFO) Start LedDevice 'adalight'.
2021-01-19T23:46:55.844Z [hyperiond LEDDEVICE] (DEBUG) (LedDevice.cpp:149:init()) deviceConfig: [{"awa_mode":true,"colorOrder":"rgb","currentLedCount":222,"delayAfterConnect":0,"hardwareLedCount":222,"latchTime":5,"lightberry_apa102_mode":false,"output":"auto","rate":2000000,"rewriteTime":5000,"type":"adalight"}]
2021-01-19T23:46:55.845Z [hyperiond LEDDEVICE] (DEBUG) (LedDevice.cpp:408:setLatchTime()) LatchTime updated to 5ms
2021-01-19T23:46:55.845Z [hyperiond LEDDEVICE] (DEBUG) (LedDevice.cpp:429:setRewriteTime()) Refresh interval = 5000ms
2021-01-19T23:46:55.845Z [hyperiond LEDDEVICE] (DEBUG) (LedDevice.cpp:435:setRewriteTime()) RewriteTime updated to 5000ms
2021-01-19T23:46:55.845Z [hyperiond LEDDEVICE] (DEBUG) (ProviderRs232.cpp:36:init()) DeviceType : adalight
2021-01-19T23:46:55.845Z [hyperiond LEDDEVICE] (DEBUG) (ProviderRs232.cpp:37:init()) LedCount : 222
2021-01-19T23:46:55.845Z [hyperiond LEDDEVICE] (DEBUG) (ProviderRs232.cpp:38:init()) ColorOrder : rgb
2021-01-19T23:46:55.845Z [hyperiond LEDDEVICE] (DEBUG) (ProviderRs232.cpp:39:init()) RefreshTime : 5000
2021-01-19T23:46:55.845Z [hyperiond LEDDEVICE] (DEBUG) (ProviderRs232.cpp:40:init()) LatchTime : 5
2021-01-19T23:46:55.845Z [hyperiond LEDDEVICE] (DEBUG) (ProviderRs232.cpp:52:init()) deviceName : auto
2021-01-19T23:46:55.845Z [hyperiond LEDDEVICE] (DEBUG) (ProviderRs232.cpp:53:init()) AutoDevice : 1
2021-01-19T23:46:55.845Z [hyperiond LEDDEVICE] (DEBUG) (ProviderRs232.cpp:54:init()) baudRate_Hz : 2000000
2021-01-19T23:46:55.846Z [hyperiond LEDDEVICE] (DEBUG) (ProviderRs232.cpp:55:init()) delayAfCon ms: 0
2021-01-19T23:46:55.846Z [hyperiond LEDDEVICE] (DEBUG) (LedDeviceAdalight.cpp:53:init()) Adalight driver with activated high speeed & data integration check AWA protocol
2021-01-19T23:46:55.846Z [hyperiond LEDDEVICE] (DEBUG) (LedDeviceAdalight.cpp:63:init()) Adalight header for 222 leds: Awa 0x00 0xdd 0x88
2021-01-19T23:46:55.849Z [hyperiond FLATBUFCONN] (INFO) Connecting to Hyperion: 127.0.0.1:19401
2021-01-19T23:46:55.858Z [hyperiond EFFECTENGINE] (INFO) Run effect "Rainbow swirl fast" on channel 0
2021-01-19T23:46:55.890Z [hyperiond LEDDEVICE] (INFO) found serial device: ttyUSB0
2021-01-19T23:46:55.890Z [hyperiond LEDDEVICE] (INFO) Opening UART: ttyUSB0
2021-01-19T23:46:55.891Z [hyperiond LEDDEVICE] (DEBUG) (ProviderRs232.cpp:141:tryOpen()) _rs232Port.open(QIODevice::ReadWrite): ttyUSB0, Baud rate [2000000]bps


As you can see in the log everithng looks fine but is not erratic they are not connecting at all. The light start to change colors and its not like an effect. When i go to the WLED app the one with serial is not showing live like the other one i have.
awawa said…
If you have no message that WLED is receiving data from HyperHDR (as on my github project page for HyperSerialWLED) then HyperSerialWLED is receiving no data at all from HyperHDR host. Did you check first if your hardware serial chip on the ESP32 is capable of 2Mb first? What is the model?
nocturno said…
This one https://smile.amazon.com/gp/product/B08FR5Y85W/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&th=1
nocturno said…
Wrong serial chip. Thank You!
Unknown said…
Configuration
libreelec + hyperion + pi4 2g + 4k hdmi splitter + analog grabber(br-112) + arduino + ws2812b 300led + 75inch lg tv

Currently, it works well without problems, but there are very fine delays (0.1 to 0.2s).

(1) If everything stays the same,
If I change from hyperion to hyperhdr, can I get rid of the delay?

(2) Does hdmi-sec work for ezcap 269?
awawa said…
1 If it isn't br-112 then I would say that there is a great chance. Maybe HyperHDR will work with that grabber but I don't support or recommend at all these analog grabbers. It was great solution before new cheap, low lag and much more capable devices enter the market. Also with 300led and Arduino (guess at @500 000) probable you have max refresh rate around 15Hz on the led strip so if you want to improve that then you must migrate to one of ESP8266/ESP32 solution with voltage level shifter.

2 No, CEC is not working with any USB grabber because in that subject HyperHDR is independent from the system and only analyzes USB device (video signal detection). All the system screen grabbers were removed from HyperHDR because they are problematic (can conflict with the system and/or video players) and completely unperceptive in terms of high quality screen capturing (4k/HDR) due to DRM.
Unknown said…
Thank you for your detailed answer.

Unfortunately, hdmi-sec is not working.

I have both products, rullz ms2109 usb2.0 and usb3.0.

The reason for using analog is because of usb 2.0, 3.0 hdmi grabber in hyperion.
Even if you change the setting, the delay is greater than the analog grabber.

(1) I can't feel it on the regular screen and I can feel the delay when I change the screen quickly. Can I make the delay to zero if I install Hyperhdr and use the hdmi grabber?


(2)usb2.0 is black without a signal, and usb3.0 appears on the screen without the rainbow bar turning off. Is there a solution?
awawa said…
Again guessing that rullz you tried to use forced mjpeg encoding and with Hyperion NG I didn't manage to have more than a few per seconds either with one CPU core stack at 100% while other 3 wasn't used.
You can configure signal detection providing coordinates for blue bar from rainbow signal (set blue tolerance high, red and green very low) in the grabber configuration. For the all black image is even simpler. I'm not using signal detection but from the feedback from the users know that it's working quite good.
Jeireff said…
Hi,
at first thank you very much for the time and work you invested in this. Sadly, I found this a bit too late and I've invested a a lot of money in Hardware just to find out that HDR makes problems with my Setup and the ambilight is delayed as hell. But before I will change my whole setup I would like to ask you if you can help me out with another solution.

This is the splitter I allready own (and it seems like it works very well):
https://www.amazon.de/gp/product/B083JVPXDY/ref=ppx_yo_dt_b_asin_title_o04_s01?ie=UTF8&psc=1

Is there any capute device I can use with this splitter to have a good HDR result and no delay on the ambilight? I think, its my capture stick which make the expiriance so bad.

This is my capture device btw:
https://www.amazon.de/gp/product/B0895N9KM5/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1

Thank you for your help (and sorry for the bad english, its not my first language)
awawa said…
That grabber looks like MS2109 clone but you must check its specification. Under Linux its done with 'usb-devices' command.
Read here more about it: https://hyperhdr.blogspot.com/2020/11/grabber-for-hyperhdr-rullz-usb-20.html

If it's MS2109 then I can assure that the capture device is not your problem but some other/others element in the ambilight ring. That capture device has a lag around 100-300ms depends on the mode and encoding. Even with 300ms in worst case scenario it should not be perceived as 'hellish' delay ;)

Splitter is OK, typical. Sometimes some "magicians" on various forums try to persuade people to buy some EZCOOTECH or other magic splitter with "new, magic" software as workaround for every HDR/DV problem. It's a scam. As for today there is no other, affordable hardware solution for both HDR/DV than a high-end amplifier or HD fury. But to split HDMI signal that ezcoo model is perfectly fine.
Jeireff said…
Thank you for your response! I have now installed your HyperHDR and the lag is gone. That's awesome. You have to be some kind of magician;) The last thing I have to get rid of is the problem of (light) blue instead of white while the image comes from the capture device. When I start the LED-Test -Effect, white seems fine. By the way, I use the ws2801. But maybe I can fix this by myself while randomly changing things in the settings: D Anyway. Thank you so much for all the effort you put in this pice of software. I was really upset about the HDR problem and now I'm so happy... Is there maybe a way to donate you a cup of coffee?
awawa said…
I'm very happy that it helped you. If you have no blueish led color on the video preview (upper right corner) then probably these my default settings in the "Image processing" tab cause your a problem ;) Effects don't use calibration so they can bypass it. There is a warning on github home project about it but I promise to reset them to the default in the next release :) I have a light beige wall so I need a bit more of blue component.
Just reset all gammas to 1.5 and all colors above to have 0 or 255 (which is closer) values: nothing between.
I appreciate your offer but as long as there is no possibility to send a beer by using some kind of github service there is nothing that can be done unfortunately ;)
Regards and have fun!
Jeireff said…
I will try to test this at the weekend. Thank you very much for everything.
Unknown said…
I've installed the hyperhdr well, and I think it's working.

It's all thanks to your good teaching. That's amazing!

Below is the hyperhdr log history.

2021-02-04T14:01:36.201Z [hyperiond V4L2:/DEV/VIDEO0]
(DEBUG) (V4L2Grabber.cpp:1137:process_image()) Video FPS: 30.00, av. delay: 7ms, good: 1800, bad: 0 (60.00,15)

As you explained, it seems to be working at delay:7ms.
This would be the best, right?

Thank you again.
awawa said…
Yes, 7ms is a very good result on Rpi. Nice work :)

Video processing lag depends on encoding format (and of course on selected resolution): YUV is much faster than MJPEG. If you enabled LUT correction for HDR->SDR tone mapping then it's a zero cost for YUV decoding (also for NV12 and i420) but not for MJPEG and RGB modes so these modes will be hit with additional lag.

The total lag is:
- lag of the grabber (50-300ms)
- HyperHDR video processing explained above
- captured image to led strip color computing. Typically up to 1-2ms/ per instance, large areas for ex. Philips Hue could take more.
- smoothing if enabled by user
- and finally lag of the led strip controller. Arduino could take even 50ms, on the other hand built-in SPI/PWM and HyperSerialEsp8266 are extremely fast, WLED is also very fast if doesn't suffer from package lost or re-handshake due to weak WiFi signal.
Unknown said…
Yes. I wanted to change it to WLED after seeing the answer. Is it difficult to install the program? Can you recommend an article to know how to install it? I want to try it!
awawa said…
WLED's wiki documentation at github. I think it's quite well described.
Scotty said…
Hey HyperHDR, you are awesome first off. Second off, could you list out the best hardware to buy for HyperHDR? Specifically capture card, Raspberry Pi model and LEDs?

I have a Raspberry Pi 4 2gb, WS2812b RGB run through GPIO18 with logic level shifter), EZCAP269, Nvidia Shield and HDR 4k TV.

With that setup, is the best Ambilight possible today (with HDR and 4K) going to work? I understand there may be tweaks to make it better over time but is there a better hardware capture card you would suggest? You talk a lot about MS2109 and EZCAP 320 but I'm not sure if they are better or just different.

I just want my CEC to work (soundbar is in between TV and Nvidia) and my HDR to be decently represented by the leds.
awawa said…
Hi Scotty :)
Ezcap 320 with LUT table provides best color experience for 1080p HDR as for today but can't recommend it for 4k (missing 4k 23/24Hz modes). Also there is no bitstream sound pass-thru (only PCM) but this can be workaround with splitter. And I let my TV do 1080p->4k up-scaling.

I would stick with Ezcap 269. MS2109 is a great product but without a loop and rather budget one (low framerate for YUV capturing).
Probable next upgrade would be high-end sound amplifier like Denon 2700 that can do hardware level video format conversion. But it's costly one solution. I don't use CEC so can't help with that matter.
Unknown said…
Hello
I installed and ran esp8266 with your guidance.
As you said, there is no delay at all.
That's amazing. Thank you!

However, the led trembles intermittently and slightly.
What am I missing?
awawa said…
If it happens on static color and it only trembles without any violent blinking or random changing colors and there are a common ground and a level shifter then it's probable voltage or connection issue. On WLED wiki you can find schematic to include a capacitor and resistor that could help in similar cases but I never need them: guess it depends how well power supply can stabilize the current. Some types of led strip have very low PWM and some people can notice it as non-constant light stream too. And again, some type of led strip are more prone to micro voltage surges and color changing than others for example SK6812 is much more resistant than WS2812b, but has lower PWM than WS2813.
Unknown said…
Yes, that's right. It occurs in static colors.
It's the same regardless of whether there is a level shifter or not.

Unlike arduino, esp8266 needs a more stable current.
I will try to reinforce the current.

Thank you:)
awawa said…
If the Arduino works without trembles, then I would check the connections again and make sure that there is a common ground. It should not matter if the driver is Arduino or esp8266 if the level shifter is included because they are not participating in power supplying (or at least they should not be included in that part). Check a voltage on the led strip using a multi-meter anyway.
Unknown said…
I have a fatal problem with my product...
1. esp8266 is not working...No response
2. When you connect an arduino, it's working and blinks in a different color.
Only a fraction of the end lights up.
3. In the hyperhdr web, the remote control - led device moves from side to side and repeats on off.

It is the same symptom when reinstalling hyperhdr.

You must be busy, too.
I'm sorry I always asked for your help.
I've been trying to fix it for two days and I don't know how
awawa said…
As its probable more complicated please create a topic in a discussion and attach full 2 logs from HyperHDR(one for HyperSerial8266 and one for arduino working at least for one minute). Hope you remember to turn AWA protocol ON for HyperSerial8266 and turn it off for Arduino?
awawa said…
https://github.com/awawa-dev/HyperHDR/discussions
Unknown said…
Hello,
first of all thanks for hard work, the project is really great and i am enjoying hdr ambilight every day :)

i got my brand new ms2109 today but i am not sure which mode and which resolution i should take. What is your recommendation?

MJPEG or YUV?
1920x1080 or 1280x1024?
i only use a fire tv stick so i think 30 fps should be fine

i am using a pi4 with a ws2801

1080p with mjpeg have a very high cpu usage, but with YUV its lagging
awawa said…
Hi
I'm glad you enjoy your ambilight system :) Generally YUV is preferred over MJPEG. For MJPEG video frames are smaller, take less USB bandwidth but then on RPi we have to decode then and it's a very heavy process for CPU. MJPEG can introduce some unpleasant artifacts but I observed then using Ezcap 269, not with ms2109. YUV is raw format, frames are much larger and take more bandwidth (especially for 1080p it's quite a large frame). I don't see any reason why YUV is lagging and MJPEG is not using the same video resolution, other than saturated USB bus.

Video resolution is your personal choice limited only by the grabber capabilities (although you can use 'quarter of frame mode' for software size reduction). I use 720x480 on my ezcap 320 and it's enough for me. 30 fps for grabber is OK for most movies as they usually use ~24fps.
Unknown said…
Hi there,

I have a xolorspace splitter that can downscale 4k to 1080p and that is fed from my HDMI B output from my Sony DnR1080 amp so any HDR / Dolby vision is sent direct to the TV so no issues with audio or pic, what is the best capture device to use with hyperHDR and a rpi4 please
awawa said…
Hi
Why not MS2109 clone? If the low latency is a priority then check Ezcap 320/321/322: all should have latency below 50ms. Of these, the Ezcap 320 has the best support.
Kevin said…
There maybe something in the middle.
I took a gamble with one listed on amazon that stated usb 3.0 and specifically stated it did 60fps on YUYV.
The price was 13$ cdn so even if it turned out to be a MS2109 clone then I only wasted about 3$ cdn.

*I have not setup HyperHDR yet so this device hasnt been tested with it, however based on the below information everything indicates it should work, buyer beware*

Link is:
https://www.amazon.ca/gp/product/B08834R4L7/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

This is not an affiliate link and I have no links to the seller. Just a person looking for the best and cheapest equipment and wanted to share my experiences.

Sure enough, the one I received does in fact connect with usb 3(5gbps)
"cat /sys/bus/usb/devices/2-1/speed" outputs:
5000


lsusb returns:
Bus 001 Device 006: ID 1bcf:2c99 Sunplus Innovation Technology Inc. UHD Capture

"v4l2-ctl --device /dev/video0 --list-formats-ext" while connected to usb 3.0 returns:
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture

[0]: 'YUYV' (YUYV 4:2:2)
Size: Discrete 1920x1080
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 640x480
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 800x600
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1024x768
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1280x720
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1280x960
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1280x1024
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1360x768
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1400x900
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1440x900
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1920x1080
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)
Interval: Discrete 0.017s (60.000 fps)
Interval: Discrete 0.033s (30.000 fps)




Once thing noticed is that MJPG is only displayed while connecting to USB2.0, not while in USB3.0 mode.
First thought was that maybe they were spoofing it so I loaded up Guvcview and compaired between being connected to usb 2.0 and usb 3.0 while monitoring cpu usage.
CPU usage was about half when connected to usb3.0 at the same resolution/fps.
Changing resolution and fps resulted in expected drops/increases in CPU load.

Latency on usb2 or usb3 using an i5 laptop running Linux Mint is great. I cant perceive any delays but I'm also not a gamer so take it with a grain of salt.

Taking it apart, the vxis chipsets (VXIS VS9989 and VS2828) have heatpads sinking heat to the alum case.
The ITE IT66021FN chip is not heatsinked.
There is also a MX25L5121E spi flash chip.

block diagram is similar to https://github.com/maximus64/vxis-capture-fw-mod
however it goes from HDMI port>ITE IT66021FN>VS9989>VS2828>USB port

I have no idea if this combination can do HDR>SDR conversion (unlikely but thankfully we have HyperHDR!! ;) ), however for 3$ more, you get a usb 3.0 port and YUYV at 1080p/60fps.
Not bad for the price difference.

Unfortunately I dont have an HDR tv yet so I cant test how it handles HDR.

Anyways wanted to share in case it helps someone else.
awawa said…
Thanks for the detailed info, I will have it on my radar. I'm searching for new MS2109 alternative as it seems that its YUV streams is non-standard, full range and it doesn't look so good even compared to the same source MJPEG stream. At least under Windows, but since it's UVC class device the problem is probably non-OS related. Unfortunately more and more new USB grabbers do something to the SDR to HDR transformation: they can't transforms a color space (and we have purple instead of blue and broken green channel) so they simply bump the luminescence. But then we need to reduce it creating custom LUT table with reduced gain.
jingato said…
Hi, I recently purchased the Lymi 3 and I've been pretty disappointed with it, especially with the colors on HDR content. I'm looking to pit together my own DIY and have been looking to see if there are any newer capture devices. I found two that look good and can be purchased right from Amazon.

First one is the excap GameDock Ultra
and the second is the EVGA XR1 Pro

Do you have any experience with either and know if they would work well with hyperHDR? Both devices say they capture in HDR, does that mean I still need the hyperHDR version over hyperion?
awawa said…
@jingato no, I haven't tested them. The question is whether they provide proper tone mapping or whether it's about passing the HDR signal mainly. You can use HyperHDR also for standard capture, best video performance and many new features that were recently introduced in the latest version v20beta1. Moreover, even SDR capture sometimes requires a special approach (because the conversion of YUV to RGB is not standardized), which is possible in HyperHDR thanks to calibration.