Re: Debian policy on multimedia ?
On Thu, 16 Feb 2006 23:49:57 +0100, Junichi Uekawa <dancer@netfort.gr.jp> wrote:
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.
I would imaging it would take some time, since data bandwidth for
realtime video is higher than audio. If we could blindly decompress
everything and shift uncompressed data through PCI and memory bus
without problem, that might be the lowest common denominator, but I
don't know if that's going to work out for HDTV etc resolutions.
Certainly not. You don't always need uncompressed video inside the
computer.
* Sometimes, you only need to pipe an opaque stream of data
from one device to another.
* Sometimes, you need to re-encapsulate a stream of data into
a different container, leaving the stream untouched.
* Sometimes you need a user-space processor that is aware of the
compression, and handles compressed content optimally
The common audio/video framework should support data streams at
different "inspection" levels: Opaque stream, several unmuxed partial
streams, sequence of opaque frames, decoded streams...
etc. Gstreamer gets pretty close, as far as I can tell.
> 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?
The proxies (arts, esound etc.) are innocent-looking, but actually harmful in that they currently
1. add much latency in the scene
2. occupy ALSA/OSS devices exclusively so that other apps cannot use.
I don't think I've heard of any app that supports arts/esd etc. which
doesn't support saner sound protocols; so 'letting them die their
peaceful death' is a feasible option.
Such applications may exist. How about KDE? Does not KDE pretty
much assume artsd? Is it worth the effort to "un-assume" arts for
all of KDE? It might be, but we should assess the amount of work,
and the possible regressions.
--
Herman Robak
Reply to: