Delay in leds from what is displayed using video grabber

  • 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)

  • 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

  • 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)



    config.text
    # For more options and information see
    # http://rpf.io/configtxt
    # Some settings may impact device functionality. See link above for details


    # uncomment if you get no picture on HDMI for a default "safe" mode
    #hdmi_safe=1


    # uncomment this if your display has a black border of unused pixels visible
    # and your display can output without overscan
    disable_overscan=1


    # uncomment the following to adjust overscan. Use positive numbers if console
    # goes off screen, and negative if there is too much border
    #overscan_left=16
    #overscan_right=16
    #overscan_top=16
    #overscan_bottom=16


    # uncomment to force a console size. By default it will be display's size minus
    # overscan.
    framebuffer_width=1920
    framebuffer_height=1080


    # uncomment if hdmi display is not detected and composite is being output
    hdmi_force_hotplug=1


    # uncomment to force a specific HDMI mode (this will force VGA)
    #hdmi_group=1
    #hdmi_mode=1


    # uncomment to force a HDMI mode rather than DVI. This can make audio work in
    # DMT (computer monitor) modes
    #hdmi_drive=2


    # uncomment to increase signal to HDMI, if you have interference, blanking, or
    # no display
    #config_hdmi_boost=4


    # uncomment for composite PAL
    #sdtv_mode=2


    # uncomment to overclock the arm. 700 MHz is the default.
    arm_freq=850
    force_turbo=1
    max_usb_current=1


    # Uncomment some or all of these to enable the optional hardware interfaces
    dtparam=i2c_arm=on
    dtparam=i2s=on
    dtparam=spi=on


    # Uncomment this to enable infrared communication.
    #dtoverlay=gpio-ir,gpio_pin=17
    #dtoverlay=gpio-ir-tx,gpio_pin=18


    # Additional overlays and parameters are documented /boot/overlays/README


    # Enable audio (loads snd_bcm2835)
    dtparam=audio=on


    [pi4]
    # Enable DRM VC4 V3D driver on top of the dispmanx display stack
    #dtoverlay=vc4-fkms-v3d
    max_framebuffers=2


    [all]
    #dtoverlay=vc4-fkms-v3d
    start_x=1
    gpu_mem=128
    enable_uart=1




    goodluck!

  • 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

    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)


  • on Rpi3/ hyperion.NG / Buster


    I am using a HDMI to RCA analog converter > to UTV007 ( really simple grabber, like 8 euro's) on USB2.0, i show you my settings of the ledconfig
    size decimation is between 3 and 4


  • I am using a Nvidia Shield with the Android grabber for several years without any problems. (apa102 connected to pi zero w) absolutely no delay.


    For testing hyperion with the remaining apps I updated to hyperion ng and bought an usb capture device. Here I also see the delay @Zaborejszyn mentioned.


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


    I have an Onkyo with 2 hdmi out so 1 is dedicated for the grabber.


  • 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!

  • 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!


    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.

  • 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)

  • 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.



    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"

  • 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...

  • max_usb_current=1


    That settings doesn't change anything for Rpi 3


    @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).

  • @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

  • 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

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    I dont have that type of grabber..maybe mjpeg could improve latency, but yuyv is preferred for quality and low CPU usage.

  • 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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!