7 May
2008
7 May
'08
5:30 a.m.
Le 6 mai 08 à 23:31, Juuso Alasuutari a écrit :
Paul Davis wrote:
This could be the idea but "different callbacks" would require
handling two separated graph, that is video and audio do not run at
the same rate *and* audio callback would need to be able to interrupt
video computation (probably means different priorities for audio and
video threads...).
There has never been any disagreement with the
idea that videojack
is a
cool idea. What there has been is a widespread feeling in the JACK
developer community that the video JACK stuff has been done
suboptimally, in ways that don't reflect a good understanding of
JACK's
design, and without bothering to actually ask us "how should we do
this?" I'd love to see videojack be a part of mainline JACK, but
its not
going to happen with the current set of patches that have been
proposed.
To be honest, I was suprised that everyone else at the JACK
"summit" at
LAC2008 seemed to agree with me about that.
VideoJACK does sound nice, and it would be a shame to witness forkage
when things could be settled in a more productive manner. I'm in no
way
qualified to draft any API plans for JACK, which arguably is the
perfect
excuse for doing just that. ;)
I've understood that the current VideoJACK approach is to run two JACK
servers, one for video and one for audio. If it already works with two
completely different servers, wouldn't it also work if audio and video
ports just had different callbacks inside the same server?
The audio callback API wouldn't need to be changed in any way. Video
streaming capabilities would require adding a smallish additional API.
Here's a crude suggestion:
Post jack 2.0 I think ((-:
Stephane