Please enable AAC Support in ffmpeg

This could be a lot of work. Every plugin system/program that uses ffmpeg has to have a free package AND a non-free extra package (long story short: ffmpeg isn't shared between programs - each one has to compile it for itself).

As an aside, I don't think ffmpeg includes a conversion program itself - don't people usually end up using transcode etc?

Conversions can be done with ffmpeg easily. Even if programs won't share the ffmpeg-nonfree, why not build one and put it in multiverse anyway? FFmpeg is a common utility for converting files via the command line or shell/python scripts. The programs that are built with ffmpeg can be built with the free one, while an option to install the nonfree version is still available for people that require the ffmpeg conversion functionality.

this would be another package duplication. We are already having a hard time with xine in main and universe, and I'd love to avoid doing this with an much more ugly package again: ffmpeg

Then why not simply move this package to multiverse and enable everything? As an iPod owner trying to get DVDs converted to h264 it's a real pain having to maintain my own ffmpeg package and keep it up-to-date.

I second that. I like a lot having 3gpwiz to convert my movies so I can see them on my sony w900, but that means I always have to recompile ffmpeg and mplayer from source - which most users probably can't/won't do.

moving the package to multiverse is not an option, since all packages which need ffmpeg as build depends would have to be moved to multiverse as well.

I need this thing fixed. Without it, I simply can not encode my movies for my cellphone (which is mp4+aac). I need AAC support. Please recompile ffmpeg with AAC support faad/faac. This is being going on for a long time and the ubuntu forums have a lot of posts about this problem, people need a solution. Please fix ffmpeg.

It's not a simple matter of saying "fix ffmpeg". It is very inconvenient to maintain two instances of a package. As Reinhard said 6 months ago, we can't just move it to multiverse either. The obvious solution is to, you know.... not use stupid proprietary codecs?

Since ffmpeg is now in main, the AAC libraries (faac/faad) would need to go to main as well. Please, someone request a MainInclusionRequest for feisty+1.

>The obvious solution is to, you know.... not use stupid proprietary codecs?

William, this is NOT a solution. This is not about creating a video to watch on my computer. If that was the case I would have used Ogg/theora. But I am trying to get a video on my cellphone. Cellphones use either the very low quality 3GP format, or the better MP4+AAC. They don't playback anything else. As you can understand, I can't do anything about it, I can't change the industry. I need AAC.

>the AAC libraries (faac/faad) would need to go to main

Please note that the problem is not installing the faac/faad packages. The problem is recompiling ffmpeg with these options: --enable-faad --enable-faac
Without specifically recompiling ffmpeg with these options, having faac/faad installed won't help.

BTW, apparently there are apps that have two packages in the repos, like totem-gstreamer and totem-xine and a few other too. I don't think it would be difficult to provide ffmpeg with and without AAC because there is no break of apps that depend on ffmpeg. They are largely compatible builds.

I also agree that this is not the way to change the industry. Sometimes this open source philosophy seems like something religious and thats really bad for the users.
Just in case someone is looking for a solution while this subject is discussed, I would recommend this guide: http://po-ru.com/diary/bleeding-edge-ffmpeg-on-ubuntu-feisty/

I'm rejecting this bug as based on discussions from UDS-Sevilla. Please see https://wiki.ubuntu.com/UbuntuDevelopment/MultimediaPackagesPolicy for a summary of the decision.

Rheinhard: The policy prohibits us from providing an AAC implementation in main or universe, but the bug is (nevertheless) valid. It should stay as an open wishlist until someone has provided a mechanism for producing alternative builds depending on whether it's targetted at main or multiverse.

Maybe you should ask Medibuntu to package ffmpeg with aac support?

Przemysław Kulczycki <email address hidden> writes:

> Maybe you should ask Medibuntu to package ffmpeg with aac support?

This wouldn't help ubuntu users. Perhaps you can open another bugtask
for medibuntu here, if they want to handle it.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Medibuntu is a repository for Ubuntu, not a separate distribution. Medibuntu carries various legally suspicious packages already.

Also, anyone can contribute to universe/multiverse, so feel free to create and offer the perfect ffmpeg-extracodecs package or similar for inclusion. Creating a quality debian package that interacts perfectly with the rest of the system while alternative packages exist requires a lot of packaging skills, though.

Why is the library not shared anyway?

Timo Jyrinki <email address hidden> writes:

> Medibuntu is a repository for Ubuntu, not a separate distribution.
> Medibuntu carries various legally suspicious packages already.

Ah, I've thought that. Unfortunately, this doesn't really help ubuntu
users. Only ubuntu users who enable an extra repository, which is
unsupportable by us developers.

> Also, anyone can contribute to universe/multiverse, so feel free to
> create and offer the perfect ffmpeg-extracodecs package or similar for
> inclusion. Creating a quality debian package that interacts perfectly
> with the rest of the system while alternative packages exist requires a
> lot of packaging skills, though.

exactly. That's why this bug remains open until someone manages to do
that.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Isn't possible to have ffmpeg compiled with AAC support but with faac and faad only as suggested dependency?

Bordiga Giacomo <email address hidden> writes:

> Isn't possible to have ffmpeg compiled with AAC support but with faac
> and faad only as suggested dependency?

not without massive code duplication, which we cannot support. If you
find a solution, please let me know.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

maybeway36 <email address hidden> writes:

> Why is the library not shared anyway?

the debian/ubuntu version of ffmpeg is shared.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

ffmpeg already has support for using libfaad as a runtime dependency rather than a build-time one (though the header file would need to be shipped in the source package in that case). Adding support for faac as well doesn't look especially hard.

ok, is anyone working on it then? Matthew?
It's been a long time, and we STILL can't encode for our devices! PSP, PS3, iPod, iPhone, Symbian S60 v3.1+ etc etc etc.

Matthew, I have some free time on my hands. If you guys point me to the right direction, I think I can handle this and generate a patch. Are there docs about the build process I could read or info about this work I should know to start? Thanks.

Rodrigo Vieira Couto <email address hidden> writes:

> Matthew, I have some free time on my hands. If you guys point me to the
> right direction, I think I can handle this and generate a patch. Are
> there docs about the build process I could read or info about this work
> I should know to start? Thanks.

In order to fix this, ffmpeg needs to be build against libfaad. That
package is currently in multiverse and would need to be promoted to
main before ffmpeg can build against it.

For further details please read

https://wiki.ubuntu.com/MainInclusionProcess

and

https://wiki.ubuntu.com/UbuntuDevelopment

for general information about ubuntu development.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

I believe it's important to have two versions of ffmpeg. One that's as it is now, and one that has AAC and AMR support. You see, it's not just AAC that's missing, but also the AMR support that lets you encode 3GP videos for cellphones. And the AMR guys are even more strict than Dolby who chases away everyone who touches AAC. So I think that it makes sense to create a version of ffmpeg that has full support for the non-free stuff, rather than just AAC. The medibuntu guys are compiling ffmpeg correctly, with all the needed deps.

Eugenia Loli-Queru <email address hidden> writes:

> And the AMR guys are even more strict than Dolby who chases away
> everyone who touches AAC. [...] The medibuntu guys are compiling
> ffmpeg correctly, with all the needed deps.

so why there are not chased by dolby?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Not too popular yet, I guess.

Another approach would be to backport this patch:

http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/71215

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

I have uploaded test packages to ~motumedia that load the libfaad library at runtime. This would be acceptable for inclusing into ubuntu.

please test the packages from http://launchpad.net/~motumedia/+archive

and give me feedback if they work for you!

I added yoiur Hardy resource, but the upgrade app says that it can't authenticate these:
ffmpeg
gstreamer0.10-ffmpeg
libavcodec51
libavdevice52
libavformat52
libavutil49
libpostproc51
libquicktime1
libswscale0
libxine1
libxine1-bin
libxine1-console
libxine1-ffmpeg
libxine1-gnome
libxine1-misc-plugins
libxine1-plugins
libxine1-x
vlc
vlc-nox
vlc-plugin-alsa
vlc-plugin-pulse

Any ideas? Also, have you compiled in the Dirac BBC codec, and the Avid DNxHD codec? These codecs are available for ffmpeg you see, and completely free to use, it would be a shame if they are not compiled in as well.

Eugenia Loli-Queru <email address hidden> writes:

> I added yoiur Hardy resource,

the fix I mentioned is intrepid only ATM.

> Any ideas?

recompile / upload the intrepid sources for hardy

> Also, have you compiled in the Dirac BBC codec, and the Avid
> DNxHD codec?

No, that requires a later ffmpeg snapshot. that will be done for
jaunty. I'm currently working on that in debian/experimental.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

This bug was fixed in the package ffmpeg-debian - 3:0.svn20080206-12ubuntu2

---------------
ffmpeg-debian (3:0.svn20080206-12ubuntu2) intrepid; urgency=low

  * Replace Vcs-Svn headers with Vcs-Bzr header
  * enable libfaad support via dlopen(). LP: #6366
  * enable liba52 support via dlopen(). LP: #197133
  * add libfaad0 and liba52-0.7.4, to Suggests of libavcodec51
  * Adjust sonames used by dlopen() on liba52 and libfaad in liba52.c and
    libfaad.c

    This change has been staged in the motumedia PPA and verified by
    myself. While doing this the new patch
    51_dlopen_correct_libfaad_and_liba52_so.diff has been created.

 -- Reinhard Tartler <email address hidden> Fri, 26 Sep 2008 19:56:10 +0200

What would be the correct -acodec parameter to encode with aac support using the libfaad package?

I tried -acodec aac|libfaad|libfaad0 without success.

I have the same issue as Yves. I have libfaac0 and libfaad0 installed. I'm on Karmic. On Jaunty I could encode videos with ffmpeg that my phone (which has Symbian S60 5th edition) could play. Those were .mp4 files, probably with AAC audio.

That's because Ubuntu removed AAC from ffmpeg even from the "unrestricted" version of it. I guess they either got a call from the suits, or they are afraid of the suits.

When I upgraded to Karmic, I had to rebuild ffmpeg from source with aac support. Ever since, it doesn't work correctly. The sound quality is significantly degraded when encoding wav to aac, even on audio that previously worked fine with the exact same settings.

So something is definitely wrong now, so building a repo package would be far preferable.