Andrea Cremaschi

Forum Replies Created

Viewing 20 posts - 1 through 20 (of 28 total)
  • Author
    Posts
  • in reply to: Syphon Virtual Screen (again!) #39681
    Andrea Cremaschi
    Participant

    Hi boya,
    sorry, no clues, I have never tried to make it work with FCPX. As it is working with qlab it should be correctly registered as a monitor, maybe it is not enough for fcpx to use it as a preview screen, some other requirement could be needed. “no problem in problem folder” is weird too, could you file an issue on github to keep track of it?
    Just for curiosity, what are you trying to accomplish?

    in reply to: Syphon Virtual Screen (again!) #35508
    Andrea Cremaschi
    Participant

    Me too..
    If you can’t do without SVS check the instructions on how to use custom resolutions on the project homepage: https://github.com/andreacremaschi/Syphon-virtual-screen

    in reply to: Syphon Virtual Screen (again!) #24906
    Andrea Cremaschi
    Participant

    Did you replace the “Syphon Virtual Screen” application in /Applications folder with the one provided in the .zip file?

    in reply to: Syphon Virtual Screen (again!) #24886
    Andrea Cremaschi
    Participant

    hi alfonso
    don’t panic 🙂 and follow this link:
    https://github.com/andreacremaschi/Syphon-virtual-screen

    Under the section “Binary” you’ll find a link to the pkg.

    hope this goes without issues, if you encounter some just tell me
    ciao
    a.

    in reply to: Syphon Virtual Screen (again!) #18890
    Andrea Cremaschi
    Participant

    Yep sorry, I did quite a mess in organizing the binaries deployment 🙂
    Now I centralized the link to the binaries on the project’s page on github, in case I’d need to change it again (hope not). Please refer to that link for the latest version.

    To check if everything is ok with the Qlab/SVS part, why don’t you use Syphon Recorder? It will give you a list of all active Syphon servers on your machine.

    in reply to: Syphon Virtual Screen (again!) #15956
    Andrea Cremaschi
    Participant

    Hi Eugenyo, happy it works.
    yes, the “freeze after wake up” bug is a known one, I think it happens in the Proxy Framebuffer kext, but since it is related to proxy programming I haven’t found a clue on how to fix it. This is the bug tracking post:
    https://github.com/andreacremaschi/Syphon-virtual-screen/issues?state=open

    in reply to: Syphon Virtual Screen (again!) #15137
    Andrea Cremaschi
    Participant

    this is the full path of the plist to edit:
    /System/Library/Extensions/EWProxyFramebuffer.kext/Contents/Info.plist

    in reply to: Syphon Virtual Screen (again!) #15134
    Andrea Cremaschi
    Participant

    Hi Eugenio,
    yes, it is possible to use a custom virtual screen size without even recompiling the framebuffer, but you have to edit the kext configuration.

    Just do this:
    – open the Terminal
    – type “sudo su”, enter, type your password
    – type “cd /System/Library/Extensions/EWSyphonProxyFramebuffer.kext/Contents/”
    – type “nano Info.plist”
    – search this section:
    MaxResolution

    height
    1024
    width
    1280

    and replace max height and width as you need to

    – a little above this section you’ll find a list of available resolutions. Add yours:

    height
    2048
    name
    2048×768
    width
    768

    – type “Ctrl+X” to save your editing

    – now, back in terminal, you have to repair permissions for the driver you’ve just modified. Type:
    “sudo chmod -R 755 /System/Library/Extensions/EWSyphonProxyFramebuffer.kext”
    “sudo chown -R root:wheel /System/Library/Extensions/EWSyphonProxyFramebuffer.kext”

    – delete the kext cache (“rmdir -R /System/Library/Caches/com.apple.kext.caches/Startup”);

    – reboot

    Let me know if everything went ok,
    a.

    in reply to: Syphon Virtual Screen (again!) #6205
    Andrea Cremaschi
    Participant

    Ok so the next step further would be to write a real virtual screen simulator (not a virtual frame buffer as ewproxyfb is), that would make the GPU driver allocate a GPU memory front-buffer. But this is far beyond my reaches, and driver documentation is really poor, and I’m sooo satisfied with this last version of SVS 🙂
    thx fernlightning, again!

    in reply to: Syphon Virtual Screen (again!) #6187
    Andrea Cremaschi
    Participant

    Yes, that will do, thank you! Too bad I can’t switch to 10.8 on my mac, or I’d be glad to test CGDisplayStream function myself: feel free to fork the project on github!

    in reply to: Syphon Virtual Screen (again!) #6178
    Andrea Cremaschi
    Participant

    @vade: thanks for the hint about CGDisplayStream, is there any reference about that? It may be worth trying. Even though handling with CoreGraphics brought me issues in the past, since I haven’t find a proper way to get the CGDisplayID of a given framebuffer/physical device.

    in reply to: Syphon Virtual Screen (again!) #6174
    Andrea Cremaschi
    Participant

    Thanks vade and anome!

    Actually, anome bugfix broke the banks: the code has been improved again (thx fernLightning!) and CPU usage is under 4% on my machine. I think it’s the best we can hope to have for non-Syphon enabled applications for now.

    https://rapidshare.com/files/3975409114/SyphonVirtualScreen.pkg

    (link above is broken)

    Happy video-output hijacking!

    in reply to: Keynote.app server.. #6170
    Andrea Cremaschi
    Participant

    Hi,
    maybe SVS could be of some help for you all: http://v002.info/forums/topic/syphon-virtual-screen-again/

    a.

    in reply to: Syphon QTKit and IP Cam Inputs #6042
    Andrea Cremaschi
    Participant

    cool! Some time ago I wrote a tool to pipe IIDC cameras to Syphon server using libiidc1394. Feel free to use the source code if you think it could be useful.
    https://github.com/micrem73/SyphonIIDCServer/tree/master/SyphonIIDCServer
    ac.

    in reply to: Virtual Screen Device #5774
    Andrea Cremaschi
    Participant
    in reply to: Virtual Screen Device #5773
    Andrea Cremaschi
    Participant

    Ok, so here it is:
    https://rapidshare.com/files/759792021/Syphon_virtual_screen.pkg

    I put all my code on a git repo: https://github.com/andreacremaschi/Syphon-virtual-screen/tree/90c64ee2983aaa99f5ecb2b1ce548e75e75bce2c
    But the application won’t work without the EWProxyFramebuffer kext driver, that is included in the installer package.

    Again: since the frame buffer reside in system RAM and not in GPU RAM this is not the best solution for everyday Syphon work, but can be helpful to hijack an application video output that is not Syphon-enabled.
    Have fun! 🙂

    in reply to: Virtual Screen Device #5772
    Andrea Cremaschi
    Participant

    Well, QLab QC support is still weak.. In fact you can write a custom patch to modify the way a single video is composed. I used to put in this composer a syphon server, but with some issues – even stability issues, when the movie is stopped and played again in short time intervals.
    What I am working on is a tool that emulate a fake monitor out, so that you can choose that monitor as the main output in QLab (and other applications), a “syphon virtual screen”. Then this output is piped to the GPU on a Syphon server for further video processing. Sort of what Soundflower does for audio, but for video..

    in reply to: Virtual Screen Device #5769
    Andrea Cremaschi
    Participant

    Well, I suppose too that AVCaptureVideoDataOutputSampleBuffer would be faster than CGDisplayCreateImage when dealing with framebuffers residing on GPU.. Sadly I have to stick with the second because the open source virtual frame buffer I am dealing with is just a chunk of RAM memory, so an upload to a GPU texture is unavoidable. I am afraid that this means also that it won’t give us GPU acceleration when rendering to the virtual screen. But still it’s great when no other choice is possible (I plan to use it to enable Syphon output for QLab).
    I’ll take a look to the private API you point out, it seems interesting..

    in reply to: Virtual Screen Device #5764
    Andrea Cremaschi
    Participant

    In CoreGraphics API I’ve found CGDisplayCreateImage that best fits the needs. This path implies a copy from the virtual device frame buffer to a new buffer in RAM, and an upload to GPU texture every timer tick. But ok, it works and it’s the best we can have.. until a tough IOKit programmer comes out.
    Coming soon.

    in reply to: Virtual Screen Device #5758
    Andrea Cremaschi
    Participant

    Bad news.. I wrote the developer, his code doesn’t deal with graphic memory but with a fake graphical framebuffer residing in RAM. 🙁
    What next? Is there somebody in this forum able to read through NVidia open source driver code and to carry on this project?
    http://opensource.apple.com/source/IOGraphics/IOGraphics-409/IONDRVSupport/

Viewing 20 posts - 1 through 20 (of 28 total)