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

WIP Windows Grabber

Discussion in 'Development' started by Brindosch, 10 May 2016.

  1. Brindosch

    Brindosch Administrator Administrator

    Messages:
    664
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    @djhansel is working on a Windows Grabber, currently just working with DX9 (DX9 games too)
    This grabber captures and send pictures of your desktop to Hyperion for further processing.

    Information: https://github.com/hanselb/HyperionScreenCap

    This thread is open for feedback and suggestions gathering :)
     
    Last edited: 11 September 2016
  2. Doc.Ex

    Doc.Ex Member

    Messages:
    73
    Hardware:
    RPi2, +PhilipsHue
    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.
     
  3. penfold42

    penfold42 Moderator Developer

    Messages:
    655
    Hardware:
    RPi1/Zero, RPi2, RPi3, 32/64bit, +Arduino, +nodeMCU/ESP8266
    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 !)
     
  4. Doc.Ex

    Doc.Ex Member

    Messages:
    73
    Hardware:
    RPi2, +PhilipsHue
    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.
     
  5. redPanther

    redPanther Moderator Developer

    Messages:
    211
    Hardware:
    RPi1/Zero, RPi2, 32/64bit, +Arduino
    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.
     
  6. Brindosch

    Brindosch Administrator Administrator

    Messages:
    664
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    Still no feedback from the developer.
    Rick forked it and added some more fixes.
    Have fun!

    //update initial post
     
  7. Rick164

    Rick164 Administrator Staff Member Administrator

    Messages:
    175
    Hardware:
    RPi2, +Arduino, +AtmoOrb
    Network lag isn't noticeable on LAN at least, the only lag is during the surface back buffer copy which is 1-5ms depending on hardware but for 60FPS that is still plenty fast :)
     
  8. HalbesHaehnchen

    HalbesHaehnchen Member

    Messages:
    33
    Hardware:
    RPi2
    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 :)
     
  9. Doc.Ex

    Doc.Ex Member

    Messages:
    73
    Hardware:
    RPi2, +PhilipsHue
    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.
     
  10. Paulchen-Panther

    Paulchen-Panther Ich komme wieder, keine Frage! Developer

    Messages:
    94
    Hardware:
    RPi1/Zero, 32/64bit, +Arduino
  11. Brindosch

    Brindosch Administrator Administrator

    Messages:
    664
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    @Doc.Ex
    the only bad repots i saw was with APUs. What hardware are you using?
     
  12. Doc.Ex

    Doc.Ex Member

    Messages:
    73
    Hardware:
    RPi2, +PhilipsHue
    Intel i5 6600K
    Nvidia GTX 970

    Maybe not the latest graphics drivers, need to check that. But maximum 2 months old.
     
  13. Rick164

    Rick164 Administrator Staff Member Administrator

    Messages:
    175
    Hardware:
    RPi2, +Arduino, +AtmoOrb
  14. Doc.Ex

    Doc.Ex Member

    Messages:
    73
    Hardware:
    RPi2, +PhilipsHue
    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 :(
     
  15. Brindosch

    Brindosch Administrator Administrator

    Messages:
    664
    Hardware:
    RPi1/Zero, RPi2, RPi3, +nodeMCU/ESP8266
    Hm, strange. I had no problems with it or any delays. I also use 2 switches, one AP and one Router.
    you disabled smoothing?
     
  16. Doc.Ex

    Doc.Ex Member

    Messages:
    73
    Hardware:
    RPi2, +PhilipsHue
    I'll fiddle around some more. Maybe I can spot the issue.
     
  17. redPanther

    redPanther Moderator Developer

    Messages:
    211
    Hardware:
    RPi1/Zero, RPi2, 32/64bit, +Arduino
    I had probs with wifi. After connecting all devices to my gb switch problems disapear and there is no latency. Perhaps you can connect rpi and pc via cable to same switch for testing ...
     
  18. Doc.Ex

    Doc.Ex Member

    Messages:
    73
    Hardware:
    RPi2, +PhilipsHue
    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?
     
  19. TPmodding

    TPmodding Administrator Staff Member Administrator

    Messages:
    781
    Hardware:
    RPi1/Zero, RPi2, RPi3, +Arduino
    Offtopic: DHCP not HDCP, sorry :D
    it should not matter in your own Home Network...try to ping it, you should have pings under 10ms...think the problem is another
     
  20. Doc.Ex

    Doc.Ex Member

    Messages:
    73
    Hardware:
    RPi2, +PhilipsHue
    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.