torbenh(a)gmx.de writes:
> /*
> * Get the number of frames in a video port buffer
> */
> jack_nframes_t
> jack_video_get_frame_count (void *port_buffer);
i dont think there would be more than one frame per process callback.
so this call is not necessary in my opinion.
I think with PAL (25Hz), you have one frame each 40ms. With interlaved
video you get 20ms. With not low latency setup you will get more than
one frame almost always.
I dont get why there should be separate thread for video. I think it
should be processed in same libjack thread. If you cannot process the
video you will get xrun. Just as with audio. So you probably need to get
faster CPU or decrease CPU usage in some way. The only reason I can
imagine is to have separate audio and video xruns semantics. So you can
drop frame without droping audio.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>