stig

hi all, is there a way to grab video stream playing from a video preview window in an external application such as Pro Tools? Years ago this could be acheived by using Synthetic Aperture's Echofire or through graphic cards supporting hardware video overlay, but none of these solutions (AFAIK) work with OS X Leopard

The nearest solution I've come across is by using jit.desktop, but it very cpu hungry and requires the video window to stay in a fixed position.

So, I'm wondering if there is some way to access video streams directly from the graphics layer/Core Graphics/Quartz or the graphic card (ATI Radeon Series)?

The nearest solution I've come across is by using jit.desktop, but it very cpu hungry and requires the video window to stay in a fixed position. 

So, I'm wondering if there is some way to access video streams directly from the graphics layer/Core Graphics/Quartz or the graphic card (ATI Radeon Series)? 

video-stream-to-jit-qt-grab

watch this space and periodically bug vade. because he's almost got 

On Oct 14, 2008, at 8:47 AM, Stig Holte wrote:

> hi all, is there a way to grab video stream playing from a video 

> preview window in an external application such as Pro Tools? Years 

> ago this could be acheived by using Synthetic Aperture's Echofire or 

> through graphic cards supporting hardware video overlay, but none of 

> these solutions (AFAIK) work with OS X Leopard

> The nearest solution I've come across is by using jit.desktop, but 

> it very cpu hungry and requires the video window to stay in a fixed 

> So, I'm wondering if there is some way to access video streams 

> directly from the graphics layer/Core Graphics/Quartz or the graphic 

watch this space and periodically bug vade.  because he's almost got  
that videoflower working.

>
> hi all, is there a way to grab video stream playing from a video  
> preview window in an external application such as Pro Tools? Years  
> ago this could be acheived by using Synthetic Aperture's Echofire or  
> through graphic cards supporting hardware video overlay, but none of  
> these solutions (AFAIK) work with OS X Leopard
>
> The nearest solution I've come across is by using jit.desktop, but  
> it very cpu hungry and requires the video window to stay in a fixed  
> position.
>
> So, I'm wondering if there is some way to access video streams  
> directly from the graphics layer/Core Graphics/Quartz or the graphic  
> card (ATI Radeon Series)?
>
> Thanks!


Well, hrm, its not quite soundflower for video, but I have a Mac OS X only GPU accelerated version of 'jit.desktop' for Quartz Composer, but it is open source, and runs very very fast. Im not experienced in writing jitter externals, but at this point, since no one has stepped up, I might as well try it?

There are two ways of doing this on OS X, one is a new 10.5 only API which allows one to grab images of occluded windows. However, the API returns only a bitmap image, not a texture. This means the function reads the texture of the window for you back to main memory. Running this often pegs the window server processes (meaning it uses a lot of CPU cycles), and is slower than grabbing the front buffer of a fullscreen windowless openGL context. The problem with what I do now (the latter openGL method) is that the content/window must be fully visible/non occluded.

Ive looked around and asked some folks better ways of doing this, and have pretty much gotten blank stares. The answer from a the few folks willing to even consider thinking about it is that the fundamental design concepts of applications, operating systems and drivers dont allow for easy context sharing and resource sharing. This isnt to say that it is not possible, but it certainly is not easy, and at the very least would most likely require some shim library that all 3rd party video apps would agree to use and run their textures through.

You'd be surprised how usable a GPU accelerated jit.desktop would be. ive used it in performance grabbing large window areas, with little to now slowdown.

Hope this clarifies the situation a bit :)

The code for the Quartz Composer plugin is available at

Ive looked around and asked some folks better ways of doing this, and have pretty much gotten blank stares. The answer from a the few  folks willing to even consider thinking about it is that the fundamental design concepts of applications, operating systems and drivers dont allow for easy context sharing and resource sharing. This isnt to say that it is not possible, but it certainly is not easy, and at the very least would most likely require some shim library that all 3rd party video apps would agree to use and run their textures through.

You'd be surprised how usable a GPU accelerated jit.desktop would be. ive used it in performance grabbing large window areas, with little to now slowdown. 

To explain a bit more, I should state that *inter application* resource sharing *on the GPU* is not really possible. There *are* apis for doing this on the CPU, for inter process communication. However, one looses all the benefits of speed when doing that.

Of course, im not one to say it is not possible (I wont make that mistake), but it is above my means, and it seems few others are looking in to viable solutions.

Hi Vade, thanks for your answers and for sharing your Screen Capture solution, it is highly appreciated! I have been testing it through DIPS3v2 and it works great for capture into Max4. Due to DIPS's incompatibility with Max5 I still looking for an alternate solution. Is it possible to use the provided qtz-file through jit.qt.movie? (no success so far going this route)

I just read that Barry Threw is about to port it to Jitter, I was just wondering if the features listed below will be available:

- option to select which display to capture from if more than one display is connected?

- downscaling of the captured matrix? (in order to minimize data flow/optimizing speed if doing a matrix readback from VRAM to RAM)

I just read that Barry Threw is about to port it to Jitter, I was just wondering if the features listed below will be available: 

video stream to jit.qt.grab