1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

STK1160 improvements?

Discussion in 'Development' started by Eistee, 15 August 2016.

  1. Eistee

    Eistee New Member

    after finishing my ambilight project i spent a lot of time with calibration, raspberry images and driver test. I have a WS2801 stripe with poor weaker/stronger RGB channels so calibration is essential for me.

    *** Logilink Fusicai USBTV007 Grabber ***

    After many calibation tries without getting good results, especially for red and "skin" colors, i checked the image colors the grabber produces. I recognized that the grabber image is already very oversaturated as described here by @HalbesHaehnchen:


    So it would be pointless to try to correct this with hyperion calibration if the source image already lost color information. So i wanted to disable chroma with v4l2-ctl, but after trying different images, kernels, v4l-utils versions and last checking the driver source files: There is no implementation for any v4l2-ctl commands and i don't think there will be any in future, because the linux driver is a reverse-engineered windows driver. So i was stuck with the fushicai grabber. I can't imagine how anyone gets good colors with this chip?

    *** mumbi stk1160 grabber ***

    I use v4l2-ctl to set chroma_agc=0 at startup. Then with v4l grabber default stetting (2/8) i have decent, well saturated colors and with calibration everthing is much much better than with the fushicai, but: I get "frame too small" messages and blue ambilight flashes from time to time. I digged deeply into this issue, tried a lot of things and lately i found an issue directly regarding the driver implementation. But i'm unsure if there will be any fix for this...

    *** Workaround for STK1160 flashes? ***

    As far as i understand the code in libsrc/grabber/v4l2/V4L2Grabber.cpp, if the "Frame too small" occurs the frame will be skipped? Is that the reason for the blue flashes? My idea for a workaround solution: Can we save the last valid frame und use it if the next frame is corrupt? I think it nearly won't be noticeable? And much better than blue flashes?

    I'm not familiar with C++ but i would greatly appreciate if the developers can check my idea and tell if its complete nonsence...

    Issue reference on Github: https://github.com/hyperion-project/hyperion/issues/719
    Last edited: 15 August 2016
  2. Eistee

    Eistee New Member

    No one interested in this topic? Hyperion is a great software, but without working and color-correct grabber i only have half of the ambilight fun...

    Addition: I'm in contact with the fushicai driver creator, there possibly might be some v4l2-ctl support in future, but its not sure...
  3. TPmodding

    TPmodding Administrator Staff Member Administrator

    RPi1/Zero, RPi2, RPi3, +Arduino
    Think the problem is not the interest it is more the non-existent skills :)
  4. LooseChange

    LooseChange New Member

    I started with the stk1160 in osmc and the flashing was more common than when I tried the 007. But like you, the colors are off and in my case they are way off. With the stk1160 the colors were ok after calibration but the Frame Too Small problem along with horizontal green lines in the grabbed frames made a mess. Next step will be to try openelec and hope the drivers are better.

    If there was better control of the color calibration that would be helpful. The colors with the 007 were very far off, as I mentioned in a different thread, and calibration doesn't let us shift or replace color ranges.
  5. Eistee

    Eistee New Member


    Did you make any progress with this issue?

    If the source material looses information due to color oversaturation, you will never get this information back with calibration...
  6. LooseChange

    LooseChange New Member

    I put my ambilight on ice for now, it was taking away from my tv experience with the distracting colors and the random flashing.
    Dont be discouraged though, other ppl seem to have it working well.
    I only used OSMC and I think this was the problem. Stick to openelec
  7. Bouwe Westerdijk

    Bouwe Westerdijk New Member

    For the STK1160, try this:

    "grabber-v4l2" :
    "device" : "/dev/video0",
    "input" : 0,
    "standard" : "PAL",
    "width" : 240,
    "height" : 192,
    "frameDecimation" : 2,
    "sizeDecimation" : 1,

    By changing width, height and decimation to these values I got rid of the "frame too small" errors.

    Good luck!
    • Thank you Thank you x 2