Thanks Alexandre and Simon,

It sounds like technically the task is a trivial one, thanks for the tips.

In terms of latency, I get the impression this is a function of the video capture method used...

@Simon, can you tell me which PCI card you are using?

This project is to port a piece originally done with Max/Jitter to a Pd-based system. The main complaints they had were video quality and latency, so those are problems we need to solve.

All best,

Jamie

-- http://www.jamiebullock.com

On 2 Oct 2010, at 16:13, Alexandre Castonguay wrote:

Hi Jamie,

I think it's easy to do with any of the externals handling video but here is a tutorial :

http://en.flossmanuals.net/PureData/GEMVideoMixer

I would simply add a [gemhead] -> [text2d] chain to it.

Cheers,

Alexandre

Le 10-10-02 09:43, Jamie Bullock a écrit :

...

Hi,

Does anyone know if it is possible with Pd+externals to mix 2 video streams (with the ability to crossfade between), and add a textual overlay on the mixed image (downstream keying)?

Is this possible with Gem? Gridflow?

If this is indeed possible, what sort of latency could I achieve from input to output?

Platform isn't an issue, I could use Linux, Mac OS or Windows -- whichever gives the best performance.

Any advice appreciated.

Jamie _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 03/10/10 16:37, Jamie Bullock wrote:

In terms of latency, I get the impression this is a function of the video capture method used...

@Simon, can you tell me which PCI card you are using?

This was a few years ago, I guess the current versions would be PCIe instead it was a Euresys Picolo Tetra .. 4 chips on the card, each of which switch between 4 inputs .. there are 4 BNC connectors on the card, plus extension panels with 4 BNC each for up to 16 BNC total, or make your own panel if you prefer. A nice features is that each connection has a separate termination switch, so it is fine to connect some of them in parallel, and since switching between the source is accessible from inside GEM you can get a very flexible mixer going.

It wasn't cheap, but I was very happy with it (and the overall system was hugely cheaper than any digital vision mixer capable of doing what I wanted). The company does industrial control systems using linux, so all the drivers were fine .. but actually the standard v4l ones worked well as I didn't need the extra features accessible via their drivers. I could do 4 simultaneous 640x480 feeds, and the CPU usage sending them directly to the screen was quite reasonable, allowing several other 1024x768 streams to be played from the disks. GEM (or rather openGL and the graphics card) scales the image very nicely. With the good cameras the image was very nice, though with any composite video there is not much information at better than 320x240 and it was hard to see any difference going to 640x480, the quality going via DV was better simply because DV is a cleaner, higher resolution, transfer than composite. The quality depended on the camera, not the capture. Various high definition capture systems exist, often very expensive.

Latency was the reason I switched to this system, the performance was set in a kind of low budget live TV studio, so with a camera on a person speaking the DV delay was unacceptable, the lip-sync was way too far off between the live actors voice and the image.

This project is to port a piece originally done with Max/Jitter to a Pd-based system. The main complaints they had were video quality and latency, so those are problems we need to solve.

Simon