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 [email protected] 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
