Beiträge von Zaborejszyn

Zitat von Awawa

Check with lsusb if it's macrosilicone for sure.
I'm not a fan of these grabbers but they have relatively low lag about 100ms
I dont have that type of grabber..maybe mjpeg could improve latency, but yuyv is preferred for quality and low CPU usage.

For curiosity, I checked the grabber delay by connecting it directly to the same pc from which the signal comes.

The result seems normal around 100~200 millis

Decided to play around with setting up the capture device. Setting framrate from auto to max from list (30) and size decontamination to 10 improved the delay. (640x480)
But it didn't improve enough to make it comfortable for me. I think it is about 300-700 milliseconds.

Next thing Smoothing....
Turning off smotthing improves latency to acceptable lvl but it's so flickering without it! ~100 millis
Before that post, I had to set the "Time" setting from basic 200 to 50 because then the delay was even worse.

Zitat von Awawa

@Zaborejszyn
If it's macrosilicone clone then that grabber supports both yuv&mjpeg. Which format is used by Hyperion (->logs in debug mode)?
Also check CPU usage to eliminate that botttleneck (top).

From Debug after saving capturing device settings:

2020-11-04T21:57:01.135Z [hyperiond V4L2:/DEV/VIDEO0] (INFO) available V4L2 devices:
/dev/video0 USB Video: USB Video
/dev/video14 bcm2835-isp-capture0
/dev/video15 bcm2835-isp-capture1
2020-11-04T21:57:01.135Z [hyperiond V4L2:/DEV/VIDEO0] (INFO) search for usable video device
2020-11-04T21:57:01.138Z [hyperiond V4L2:/DEV/VIDEO0] (INFO) test v4l device: /dev/video0
2020-11-04T21:57:01.139Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:696:init_device()) Set resolution to width=640 height=480
2020-11-04T21:57:01.140Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:713:init_device()) Set framerate to 20 fps
2020-11-04T21:57:01.140Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:735:init_device()) Pixel format=YUYV
2020-11-04T21:57:01.144Z [hyperiond V4L2:/DEV/VIDEO0] (INFO) found usable v4l2 device: /dev/video0 (USB Video: USB Video)
2020-11-04T21:57:01.146Z [hyperiond V4L2:/DEV/VIDEO0] (INFO) Started

CPU usage:
I chaked CPU usage with htop while using hyperion with capture card and it didn't go over 50% usage. Ram and Memory is also mostly free

Zitat von jeroen warmerdam

no i mean set protobuffer higher (image streams) > in range of 150 instead of 100. Did you see the screenshot that i borrowed from dev Paulchen Panther?
in Hyperion he said " priority is very important for running processes and devices"

I don't have problems with protobuffer and priority. Pls focus more on about what I wrote. Earlier I wrote what I have a problem with and what not...

Zitat von jeroen warmerdam

borrowed from Dev. Panther Paulchen >> https://prnt.sc/uwffdw

isn't the priority the case/ too low ??

No it's not I think
Did u mean to set priority for usb capture below 200?
I'm using mainly Proto that's why it has lower priority.
However i can switch between this to inputs in Remote Control page and turn off priority rules. That's why i think that's not the case.

Zitat von gezeebeezee

Can you elaborate a little more on what you're using to get rid of the lag? I'm having the same issue and have been trying to figure out a fix. There are lots of variables so it's hard to determine the cause.

I think I have explained several times before when I have lag and when I have not.
But I'll explain it once and for all in the end.

In hyperion I distinguish two types of image signal reception:

1. Hardware signal: "Capturing hardware" in hyperion settings. You can get such a signal by using video gabber.

2. Internet Signal: In case you don't know yet, there is a program called "Hyperion Screen Capture" for Windows 10 devices. It works almost the same as screen recording software and sends the signal through "Protocol Buffer Server" to hyperion.

I have a delay in the hardware signal, although for logic it should work faster than the signal over the internet, but for me it is unfortunately not the case.

I could use this solution, but the problem is with HDCP content. It is blocked by recording software like "Hyperion Screen Capture" or "OBS". The only option to get around this and watch full resolution content is to use hardware signals. For me, unfortunately, this solution causes the noticeable delay mentioned earlier.

We have not yet found a solution to this problem. (delay in hardware capture in my case)

Zitat von thommy86

I also have the same hardware @jeroen warmerdam has laying around, but did not have the time to test this yet.

I'm sorry I didn't answer for a while. Out of curiosity, I decided to check the solution based on UTV007 ala "EasyCAP". For me, it is even worse when it comes to receiving signals from the transmitting device, the colors are different and the image is of lower quality than from the hdmi grabber. Delay was the same about 0.5~1 sec or more witch is really distracting when scenes are changing.
I'm forced to use Hyperion Screen Capture software on computer, which is connected by internet wirelessly to raspberry pi and has not noticeable lag!

Zitat von lcnobo

It is possible that delay is from ws281x library? It is recommended to use dedicated arduino or like device led controller but without further testing, it is hard to say where the bottleneck is

I tested without the expected results even with the bitrate set to 500,000

Zitat von jeroen warmerdam

maybe has to do with PI arm and power settings, thats all i can think off. (cpu cant render the images at full speed) ?
look at the bold sections that is important for higher clockspeed and usb power on the PI
in .txt on config SD card;.. (this is mine)

I also tested it without the expected results, I can still see a ~second delay in what is displayed on the screen and the responses of the leds.

Looking at these tests, I suspect a video grabber even more.
Let's also take into account that the video grabber I ordered came in a different shape than on the website (more slim with no scraps on the sides like a USB flash drive). Maybe these "basic and cheap" noname video grabbers are like a lottery, and it could get better or worse.

Hence my request, could you recommend a good video grabber that you use yourself, for example?

I am looking for something with good latency and comatible with usb2.0

It may be worth mentioning that I do not use any video splitters etc. The signal goes directly from the computer's graphics card via HDMI and the signal to the monitor via Display port (duplicate screen on outputs)

The main reason I installed ambilight using Hyperion was to bypass the HDCP protocol when I watch netflix from my computer in full resolution. Previously, I used software similar to Hyperion cature software, but whenever I turn on the hdcp content, the signal is blocked by such software.
I put the hyperion on the raspberry pi 3, I stream the leds through the GPIO pin (ws281x) and use a common video grabber like this one.

Problem:
Noticeable time interval in leds than what is happening on the screen, around a second, which is quite distracting as scenes change etc.
I reduced the resolution of the grabber to 360p, size decimation is 8 (increasing the value does not bring the desired results), I was also afraid of the "smoothing" settings, reducing the Time value to 50 which improved the performance a little but the delay is still strongly felt.
I was starting to think that this could be a problem with such a video grabber.

I also noticed that using the Hyperion screen capture delay is not noticeable at all, which surprised me a bit (raspberry pi is connected by WLAN) but with this solution I can not enjoy the full resolution of the content and the LEDs on the back.

Can you recommend any video grabbers without delay that would work on the usb 2.0 interface? Does it make sense to buy a usb 3.0 grabber for raspberry pi 3 which only has usb 2.0? (pls with HDCP support)