7 May
2008
7 May
'08
9:08 a.m.
Well, this has been discussed to death on the
jack-devel lists. I
can see that from an audio developer's point of view,
it would be nice to have video within the same
>server as audio.
However, there are fundamental differences between video and audio,
which make
this in my mind impractical.
Firstly, there is the problem of latency - for audio,
generally the
aim is to have a latency < 4ms. For video -
since we are dealing with much larger chunks of data,
a >latency an
order of magnitude greater than this is usually acceptible.
Second, the timing is different. For audio generally
you have a 1024
sample buffer and a rate of 44.1KHz or 48KHz. Video requires
usually
something like 25fps.
So you can either have two clocks, or you can split
the video into
chunks (ugh), both solutions have problems.
If you can solve these problems, then there is
absolutely nothing
stopping you running video and audio in the same server
(Video simply adds a new port type). Regards,
Salsaman.
Video in jack1 won't happen because of several reasons that can be
explained again: we want to fix and release jack1 soon and video in
jack is a too big change to be integrated in the current state of the
proposed patch.
The future of jack is now jack2, based on the jackdmp new
implementation (http://www.grame.fr/~letz/jackdmp.html). A lot of work
has already been done in this code base that is now API equivalent to
jack2. New features are already worked on like the DBUS based control
(developed in the "control" branch) and NetJack rework (developed in
the "network" branch).
I think a combined "video + audio in a unique server" approach is
perfectly possible: this would require having 2 separated graph for
audio and video running at their own rate. Video and audio would be
done in different callbacks and thus handled in different threads
(probably running at 2 different priorities so that audio can
"interrupt" video). Obviously doing that the right way would require a
bit of work, but is probably much easier to design and implement in
jackd2 codebase.
Thus I think a better overall approach to avoid "video jack fork" is
to work in this direction, possibly by implementing video jack with
the "separated server" idea first (since is is easier to implement).
This could be started right away in a jack2 branch.
What do you think?
Stephane
7 May
7 May
5:37 p.m.
New subject: [Jack-Devel] Re : The future of videojack ?
Stéphane Letz wrote:
Video in jack1 won't happen because of several
reasons that can be
explained again: we want to fix and release jack1 soon and video in jack
is a too big change to be integrated in the current state of the
proposed patch.
The future of jack is now jack2, based on the jackdmp new implementation
(http://www.grame.fr/~letz/jackdmp.html). A lot of work has already been
done in this code base that is now API equivalent to jack2. New features
are already worked on like the DBUS based control (developed in the
"control" branch) and NetJack rework (developed in the "network"
branch).
I think a combined "video + audio in a unique server" approach is
perfectly possible: this would require having 2 separated graph for
audio and video running at their own rate. Video and audio would be done
in different callbacks and thus handled in different threads (probably
running at 2 different priorities so that audio can "interrupt" video).
Obviously doing that the right way would require a bit of work, but is
probably much easier to design and implement in jackd2 codebase.
Thus I think a better overall approach to avoid "video jack fork" is to
work in this direction, possibly by implementing video jack with the
"separated server" idea first (since is is easier to implement). This
could be started right away in a jack2 branch.
I'll throw in my 2 Euro cents.
If the VideoJACK crowd feels that JACK2 development is taking too slow
and decide to continue with their fork, may I suggest that we all still
discuss and draft a proper video API together? If a fork happens out of
practical reasons, it would be best to make sure that switching video
software to use JACK2 later on will be as painless as possible.
Technical issues aside, I wish that those affiliated with VideoJACK do
not feel that their needs are neglected by the JACK developers. I hope
that the recent discussion has proved that people in this camp are
willing to improve JACK in this respect. Perhaps we could move on and
try to find more common ground?
Juuso
6:05 p.m.
New subject: [Jack-Devel] Re : The future of videojack ?
Le 7 mai 08 à 21:37, Juuso Alasuutari a écrit :
Stéphane Letz wrote:
Yes sure.
Where is the latest state of the video patch for jack? I can have a
look and see how easy/difficult it would be to implement that in a
jackdmp/jack2 branch.
Stephane
Video in jack1 won't happen because of
several reasons that can be
explained again: we want to fix and release jack1 soon and video
in jack is a too big change to be integrated in the current state
of the proposed patch.
The future of jack is now jack2, based on the jackdmp new
implementation (http://www.grame.fr/~letz/jackdmp.html). A lot of
work has already been done in this code base that is now API
equivalent to jack2. New features are already worked on like the
DBUS based control (developed in the "control" branch) and NetJack
rework (developed in the "network" branch).
I think a combined "video + audio in a unique server" approach is
perfectly possible: this would require having 2 separated graph
for audio and video running at their own rate. Video and audio
would be done in different callbacks and thus handled in different
threads (probably running at 2 different priorities so that audio
can "interrupt" video). Obviously doing that the right way would
require a bit of work, but is probably much easier to design and
implement in jackd2 codebase.
Thus I think a better overall approach to avoid "video jack fork"
is to work in this direction, possibly by implementing video jack
with the "separated server" idea first (since is is easier to
implement). This could be started right away in a jack2 branch.
I'll throw in my 2 Euro cents.
If the VideoJACK crowd feels that JACK2 development is taking too
slow and decide to continue with their fork, may I suggest that we
all still discuss and draft a proper video API together? If a fork
happens out of practical reasons, it would be best to make sure
that switching video software to use JACK2 later on will be as
painless as possible.
Technical issues aside, I wish that those affiliated with VideoJACK
do not feel that their needs are neglected by the JACK developers.
I hope that the recent discussion has proved that people in this
camp are willing to improve JACK in this respect. Perhaps we could
move on and try to find more common ground?
Juuso
7:46 p.m.
New subject: [Jack-Devel] Re : The future of videojack ?
I'll throw in my 2 Euro cents.
If the VideoJACK crowd feels that JACK2 development is taking too
slow and decide to continue with their fork, may I suggest that we
all still discuss and draft a proper video API together? If a fork
happens out of practical reasons, it would be best to make sure
that switching video software to use JACK2 later on will be as
painless as possible.
Technical issues aside, I wish that those affiliated with VideoJACK
do not feel that their needs are neglected by the JACK developers.
I hope that the recent discussion has proved that people in this
camp are willing to improve JACK in this respect. Perhaps we could
move on and try to find more common ground?
Juuso
Yes sure.
Where is the latest state of the video patch for jack? I can have a
look and see how easy/difficult it would be to implement that in a
jackdmp/jack2 branch.
Stephane
6040
days inactive
6040
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
Juuso Alasuutari -
Stéphane Letz