[Libav-user] Questions on Different Packages

[Kip Warner]

On Tue, 2011-04-12 at 11:16 +0400, Kirill Gavrilov wrote:
> Only your 'distro' can clarify what the difference between the packages
> (however you didn't name it!).
> 
> libavcodec-dev probably contains headers (.h) and libraries (.a) for
> development (to build applications based on libavcodec).
> libavcodec-unstripped-52 probably contains unstripped binaries which can be
> used for debugging purposes;
> libavcodec52 probably the main version with dynamic library avcodec;
> libavcodec-extra-52 probably build with some extra flags or/and extra
> dependencies.
> 
> If you look here <http://packages.ubuntu.com/ru/karmic/libavcodec-extra-52>and
> here <http://packages.ubuntu.com/en/karmic/libavcodec52> you'll notice that
> extra version additionally depends on these libraries:
> 
> 
>    - libdirac0c2a <http://packages.ubuntu.com/ru/karmic/libdirac0c2a> general
>    purpose video codec - library
>    - dep: libfaad0 <http://packages.ubuntu.com/ru/karmic/libfaad0> (>=
>    2.6.1) freeware Advanced Audio Decoder - runtime files
>    - dep: libmp3lame0 <http://packages.ubuntu.com/ru/karmic/libmp3lame0> An
>    MP3 encoding library
>    - dep: libopenjpeg2 <http://packages.ubuntu.com/ru/karmic/libopenjpeg2> JPEG
>    2000 image compression/decompression librar
>    - libx264-67 <http://packages.ubuntu.com/ru/karmic/libx264-67> (>=
>    1:0.svn20090502) x264 video coding library
>    - dep: libxvidcore4
> <http://packages.ubuntu.com/ru/karmic/libxvidcore4>(>= 1:1.0.0-0.0)
> High
>    quality ISO MPEG4 codec library
> 

Thanks a lot Kirill. That was very comprehensive and helpful.

Unfortunately it looks like it is difficult for an application to be
confident that the AC3 encoder in libavcodec is always available when
libavcodec is installed, since it looks there are as many permutations
of configuration options as there are distros. I don't think any that I
have seen have the AC3 encoder enabled at configure time by default.

I'd like to have AC3 on the fly encoding to passthrough available in a
project I am working on, and I'm trying to coordinate what we need to do
to get OpenAL Soft's plumbing to properly pump its PCM to end up as AC3
passthrough.

(1) So we know that OpenAL Soft can use ALSA as its backend.

(2) ALSA has the /usr/lib/alsa-lib/libasound_module_pcm_a52.so plugin
which allows encoding on the fly to AC3.

(3) This plugin I have found is not normally built as part of
libasound2-plugins (at least not on my distro of Ubuntu Maverick).

(4) libasound_module_pcm_a52.so appears to just be the interface to the
actual encoder routines buried in ffmpeg's libavcodec.

(5) libavcodec has a shit load of different configuration time options
and different distros seem to have very different builds of it (e.g.
none that I've seen with the AC3 encoder support enabled by default).

So the good news is that we obviously don't need to write our own
encoder, of course. It's a plumbing problem. What is the most elegant
way for an OpenAL Soft client to take its incoming PCM stream and pump
out AC3 passthrough, is the question I am trying to solve. I need to do
that and make it easy for the user without stepping on any legal
landmines.

My goal is just to have AC3 passthrough available to users in my game
and without a lot of fuss, but without getting into dangerous legal
problems (e.g. there is some choice they must make to install some
specific package or something, which is simple enough to do).

We need libavcodec to do the encoding, but the user will probably have
it already installed but without the AC3 encoder enabled. Same goes for
ALSA's plugin interface to it, since it probably won't have that built
either. 

We could have a libopenal1-restricted package that prefixes within it
its own skeleton libavcodec library that has absolutely nothing enabled
in it other than the AC3 encoder (and later DTS if they ever get write
that). We would also have the

/usr/share/libopenal1/lib/libasound_module_pcm_a52.so

in there as well which would be necessary to connect the encoder with
the ALSA backend for OpenAL Soft. We would also need to find a way to
specify to ALSA at runtime to use the iec958 passthrough. I'm not sure
if we can do that progmatically, or if the user MUST specify
an .asoundrc, which is too much work for the average user.

What I am finding tricky is figuring out how to register an external
ALSA plugin at runtime, which we would need to do. I've asked on
alsa-devel at alsa-project.org twice, as well as in #alsa on Freenode, with
no response. But that is not really your problem or for this list.

Is there anything I should know about trying to build a skeleton
libavcodec that ships within our game (shared libraries prefixed within
our game root installation)?

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20110412/ea40a260/attachment.asc>