Re: Debian policy on multimedia ?
On Sun, 12 Feb 2006 15:12:01 +0100, Junichi Uekawa <email@example.com> wrote:
I have not used Video4Linux for several years. I use DV and
HDV cameras, and ieee1394 has a whole different API on Linux.
I do think that is a problem, but it may be beyond the scope of
what we are outlining here.
Yikes; at least we'd like to know the current state of problems.
What kind of protocol is that?
At least that's something worth documenting. It sounds like there is
still a lot of upstream work to be done in video field.
Indeed. A "video jack" architecure was proposed at Piksel5 in Bergen
last fall: http://www.piksel.no/pwiki/VideoJack
The video scene is still fragmented. I think Linux needs a glue
layer that unites uncompressed firewire video, compressed video over
firewire (DV, HDV, DVB), dvb and Video4Linux. Ideally, an application
that needs realtime video input, like a video chat client, should be
able to read any video input device through _one_ API.
Audio on the other hand seems to have mostly settled for ALSA and jack.
(I'm not sure if portaudio is gone?)
Yes. And I would suggest that the audio servers become deprecated.
They should get compability solutions, "proxies" if you like, so that
programs that depend on them will continue to work. But the _real_
back-ends should be ALSA and Jack. Any objections?
Ieee1394 configuration needs a policy, too. It is somewhat
worrying that the preferred device for (H)DV capture is /dev/raw1394,
which can also be a disk device!
Yes, this is too bad. It might be nice to get something implemented.
A symbollic link for DV capture device, and someone to configure it
looking at its device characteristics.
We need separate devices to get rid of the issue. You want a video
device that it's OK to chmod 666, or whatever you choose to do in order
to enable other users than root to capture and output video.
The current state of affairs is not sustainable. It has been
acknowledged, but I can't see it has been prioritised.