Re: [Fwd: Re: DV over ieee1394, v4l and arts/oss]

[Dan D. <da...@de...>]

Herman, all your points are completely valid; why did you not copy the
list? Of course, being valid and being a priority are 2 different
things :-). I have agreed to help start managing linux1394 patches, and
I have 2 contracts at the moment that is requiring focus on linux1394.
However, I am only going to be focusing on stabilisation, compatibility,
and udev issues. 

Recently, I have put a good amount of work into libiec61883, which is
nearing a release (by end of year). This new lib is the next generation
for streaming media on linux1394 including DV, MPEG2-TS, and AMDTP
(audio and music data). Today, it occurred to me that this lib, after
some maturity in userspace, could probably be ported easily into kernel
code and interfaced into v4l2 and alsa. I am not making any promises and
am still not that interested, but it is an approach I recommend to
someone considering it.


On Tue, 2004-11-23 at 10:22 +0100, Herman Robak wrote:
> On Tue, 2004-11-23 at 03:07, Richard Baverstock wrote:
> > The reply I got from Dan Dennedy regarding ieee1394 and v4l/alsa
> > 
> > -------- Forwarded Message --------
> > From: Dan Dennedy <da...@de...>
> ...
> > It is possible when somebody programs it :-). v4l2 provides a stream
> > format field that includes an enum for DV. It is not forseeable to
> > provide uncompressed video unless using the vloopback device because
> > decoding in the kernel is a no-no.
> 
>  How about getting pluggable userspace drivers?  ALSA can have
> soft synthesizers impersonating a sequencer device, after all.
> (BTW: Is there a handy mechanism for launching a synth server 
> automatically on demand?)
> 
> 
> >  Personally, I do not think it is very interesting because there
> > are mulitmedia frameworks and uberlibs like ffmpeg that already
> > support DV over 1394. Even apps that disguise their framework
> > like Xine, VLC, and mplayer can read from DV on stdin.
> 
>  But many don't.  We're not just talking players here.  I am thinking
> of NLEs, video surveillance, video conferencing ... -any software that
> uses video.  Having each application support several APIs and stream
> formats internally is a horrible lot of duplicate effort.  It holds
> back the state of the art for video on FreeNIX.
> 
> 
> > > and a seperate audio device (instead or in addition to the one
> > > (/dev/dv1394) that currently exists)? We're thinking something along the
> > > lines of how USB audio devices, when plugged in, become alsa/oss devices
> > > or appear to be alsa devices.
> > 
> > It might make more sense for audio since that area on 1394 is less
> > mature and established. However, I would expect most folks using
> > 1394-based audio devices are working on the professional level and
> > therefore using Jack. One could easily write a daemon that uses
> > libiec61883 or libraw1394 and supplies a jack connection. 
> 
>  Jack is neat, but it has a chicken-egg problem.  Currently, it does not
> work out of the box on all distros.  If you are not a _motivated_ pro,
> you may find it unusable.  As long as this is the case, the distros may
> choose to not include jack setup in their baselining tests.  Hence, it
> remains tricky, adoption is slow and time passes.  Jack becomes its own
> enemy if it's a prerequisite for too many things.
>