Windows Grabber

  • Sounds interesting, will try it within the next days.
    However I already see a problem. This grabber sends the captured information via network to hyperion, this means, depending on your network configuration, the ambilight will have a very noticeable lag.
    At the moment I am using the AVR -> splitter+converter+usb-grabber -> RPi method and also have a lag, although very little and thus tolerable. But nothing compared to when the content is grabbed directly on the Raspberry Pi.

    So my question is, would it be possible to develop a grabber that sends the information via a usb interface instead of via network? I reckon that would be a lot faster. Please bear in mind that I am by no means a developer and can not estimate realisability or required effort.

    Another solution would be to run hyperion directly on windows and send the information for the lights to the Pi via usb which only converts them to the SPI interface.
    I know something like this is possible with an arduino, however i then would not have philips hue support and would need additional hardware. That is why I like Hyperion.

    Anyway, what do you think, does this use-case make sense and does it have potential to be looked into?

    Cheers for all the work you and everyone who participated in the hyperion project has done and are doing. I am really happy to see it become more professional and am excited to see where this goes.

  • The pi can't act as a USB Slave device so that options out.

    I suspect the network latency will be ok if the grabber protocol is optimized and lowres.

    Isn't the Phillips hue network connected ?
    If so, a Windows port of hyperion could talk to it (if someone does get around to porting it !)

  • Well technically it doesn't have to be a slave. Right now the pi gets the grabbed videostream via a USB connection from the usb-grabber. If it would be possible to have a screengrabber that grabs the display output directly in windows and pushing it out via USB all the splitter/converter/grabber peripherals would become obsolete and you would have a digitally grabbed signal which should be more accurate in colour and resolution compared to analog. However I don't know if this is possible at all. I guess the Windows grabber program would need to register as a grabbing device via that specific usb connection on a specific usb port of the windows pc in order to get recognised by OS of the Pi. But again, this is all hypothetically as I am not a developer and only have rudimentary knowledge of software programming.

    To have a windows port of hyperion would be very nice. Preferably with the support to use an arduino to control the leds. This way everything, given that the windows grabber works, can be grabbed digitally, processed directly on the machine and then pushed out to the LED devices, e.g. light strip, philips hue, etc.
    That would mean very low latency, except for an arduino to control the leds no additional hardware and more accurate colours.

    Disadvantage is that this would only work for the PC as a source. At least for me this wouldn't matter since it is the only source I use, now that I have Gaming/HTPC.

  • From my experience with network transfer of frames (the hyperion forwarder) network is fast enough for this task. Important is to scale down the captured frames like e.g. the hyperon-x11 grabber does.

    For my scenarios transfer over lan is much faster as transfer with 115k to arduino over usb.

  • Works pretty well already on Win7 x64.
    I used to have an ambilight based on the "SeduBoard" and AtmoWin. SeduBoard is in the Chimney now, creating fake fire :D
    It worked fine but slowed down the whole system way to much.

    I built my Hyperion Ambilight yesterday and got it working so far with the USB grabber, but colors are wrong pretty often. And since I use an ultra widescreen its not gettin any better.
    This little tool has very accurate colors out of the box.

    Sadly it wont work with DirectX 9 game, at least not for me. I had the same problem with my first ambilight, and you had to install PlayClaw to capture the screen information ingame I assume?!:unsure:

    Thanks for this and Hyperion :)

  • Tried it today, but it doesn't work for me. It says "Failed to take Screenshot".
    Windows 10 x64.

    I have 2 monitors connected, but only one monitor is activated so I assume that is monitor 0 then.
    Also, I checked if all dependencies are installed and yes they are.

    Is it supposed to work on Windows 10? Didn't try any games or anything, just the desktop.

    • Official Post

    Working here on Windows 10 x64 so should work (GTX1080 + 368.39 drivers):) , on multi monitor setups you do have to supply the monitor index if the screen you are capturing is not the first one (primary).
    Also make sure to use the latest build:…1.2/

    Failed to capture usually means it can't get the surface so would play a bit with the monitor index.

  • I finally got the x11 grabber working. But it is stuttering. Not like it is behind what is shown on the screen, but it seems like it drops frames. I tried 60fps ands 120fps. Same result. width and height are both 64 pixels, any other value doesn't work at all. I guess it ist just my network configuration. I use a wired access point that connects to the router which handles HDCP and NAT. So the whole route of the data package is: PC -> AP -> Router -> AP -> Switch -> RPi
    Thats a shame since the colour reproduction was better with the windows grabber. But the stuttering kills it for me :(

  • Well my connections are all wired so at least there is no wifi involved. I can't really connect the pc to the switch unless I use the long network cable that runs from the switch to the AP. But then the whole system would be isolated from the router and nothing handles HDCP etc. One thing I could try is surpass the switch and let the pi directly connect to the AP. But then again the route would be PC-AP-Router-AP-Pi. Because to my understanding, all packages that are sent via the network have to go through the router that handles NAT and HDCP right? Or can the devices connect directly without the need of routing?

  • Oh yeah, DHCP :D HDCP was for the copyright protection :facepalm:
    Just did a ping from my laptop that is connected via wifi to another access point in the house and had an average ping of 16ms on 10 pings. So I guess you are right. But what could it be? My understanding is, that hyperion runs my normal grabber config, but because the windows grabber sends packages to the json/proto server with a lower priority channel, hyperion uses that information instead of the usb grabber input right? Smoothing etc comes after that? Because it somehow looks like it is a lower framerate without smoothing. Another thing I could try is to comment out the whole grabber part. Maybe that interferes somehow.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!