Re: How about: faac compatibility library using vo-aacenc

2012-06-06 Thread Rogério Brito
Hi, Sebastian.

On Tue, Jun 5, 2012 at 4:38 AM, Sebastian Dröge
sl...@circular-chaos.org wrote:
 All this ignored, the problem is that applications can assume that they
 can use e.g. the Main profile when they're linked to libfaac.

Yes, that's correct.

 Why not just change the software you care about to use vo-aacenc? The
 API of faac and vo-aacenc is not that difficult.

Sure. That's indeed the right thing to do. And the API is indeed simple.

Anyway, I have some good news here regarding handbrake: with a proper
patch that rips apart the faac things entirely, I could build, run and
even test the encoding of a video with HandBrake *without* using faac.

The last dependency is only mp4v2. Fabian, IIRC correctly, I remember
you talking with the mp4v2 upstream, is that correct? Are they willing
to license mp4v2 under something that is compatible with the GPL?

If yes, then we are even closer to an upload of handbrake to the archives.


Regards,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: How about: faac compatibility library using vo-aacenc

2012-06-06 Thread Fabian Greffrath

Am 06.06.2012 12:26, schrieb Rogério Brito:

The last dependency is only mp4v2. Fabian, IIRC correctly, I remember
you talking with the mp4v2 upstream, is that correct? Are they willing
to license mp4v2 under something that is compatible with the GPL?


No, sorry. I have never contacted mp4v2 upstream about this (and - 
honestly - I don't believe there is anything they can do about this 
even if they wanted).


I was once talking with gtkpod upstream about their GPL-licensed 
MP4-plugin that linked against mp4v2 and was thus unredistributable. 
But they have resolved this issue differently, i.e. by using 
atomicparsley instead. Maybe you mixed this up...


 - Fabian


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

RFC: Getting HandBrake working in Debian (was: Re: How about: faac compatibility library using vo-aacenc)

2012-06-06 Thread Rogério Brito
On Jun 06 2012, Fabian Greffrath wrote:
 I was once talking with gtkpod upstream about their GPL-licensed
 MP4-plugin that linked against mp4v2 and was thus unredistributable.
 But they have resolved this issue differently, i.e. by using
 atomicparsley instead. Maybe you mixed this up...

Oh, quite probably I mixed those up. Then someone will have to see how to
substitute mp4v2 with something else (libav?). I hope to have some time for
doing that, but I honestly don't know.

BTW, can any of you (preferrably, many of you) test what I have put so far
in our repositories? It would be nice to get some feedback on many things
there.

I tried to put moderately descriptive comments on the commits that I thought
that mattered when I felt that the solution that I took was more of a
dirty workaround than a proper solution.

In fact, given that this is pure work-in-progress, I would love to have
external comments on what to change so that I can limit my divergence from a
good, proper solution.


Regards,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: How about: faac compatibility library using vo-aacenc

2012-06-05 Thread Rogério Brito
Hi there.

On May 27 2012, Fabian Greffrath wrote:
 Do you think it is possible / feasible to develop a library that provides
 the libfaac API but uses vo-aacenc for the actual encoding?

Yes, it is. I am (slowly) studying how the vo-aacenc library works and I
expect to duplicate the example aac-enc.c that is in the vo-aacenc git tree
with some code of my own, but vo-aacenc has a lot of limitations that
libfaac doesn't.

Perhaps implementing the libfaac API can be done with some stub functions,
until the aac encoder of libav/ffmpeg matures to the point of being usable.

That being said, handbrake already allows one to use multiple libraries for
encoding audio in a video.

Recent versions of handbrake can, for generating a video with audio in AAC,
use libfaac, an AAC passthrough, libav/ffmpeg and, on MacOS X, use
CoreAudio.

See a screenshot that I made from a recent compilation of the packaging that
I'm sending to the git repo at alioth with a recent git snapshot of
HandBrake's tree:

http://www.ime.usp.br/~rbrito/debian/handbrake-aac.png

 This would help applications that unconditionally depend on libfaac,
 e.g. handbrake, to make it nito Debian until they are cleanly ported
 either directly to vo-aacenc or to only conditionally depend on libfaac.

I'm not so sure about the unconditionally part above (but then, I have not
tried that yet, to avoid me getting so dispersed with many tasks to try and
not finishing anything).

I would love it if you tried to tweak what I uploaded to alioth and let me
know what works and what doesn't.

 Is there anyone on this list who has experiences in this kind of
 compatibility APIs or a concrete idea of how an implementation could look
 like?

My plans would be to mimic one of the files under libh (like
enc{faac,avcodec,lame}.c) and start from there. If I end up with something
that works, I will offer it to upstream.

BTW, do you want to try to work with me on this, Fabian (or anybody else)?

Perhaps also taking the mpeg4 container from libav or from gtkpod
(atomicparsley?) we can get a stripped down (but *Free*) implementation of
the faac command-line tool?

If things prove to be OK, we can, perhaps, mine the patches from faac that
are GPL and integrate them into this potential library, to fill in some of
the gaps that vo-aacenc has (encoding in more than 2 channels etc).

Of course, some of the stuff that I listed above may be some longer term
goals and need investigation, but it will be nice to try, at least (even if
destined to fail). :)

 For example, what to do if features of libfaac are requested that are not
 yet implemented by vo-aacenc, Warn or Abort?

Simply gray out things in a user interface (in the particular case of
HandBrake). For a library, return some error to the caller would be
appropriate.


Regards,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: How about: faac compatibility library using vo-aacenc

2012-06-05 Thread Rogério Brito
On Jun 04 2012, Sebastian Dröge wrote:
 Last time I checked vo-aacenc did not support more than 2 channels and

Yes.

 also only the low-complexity AAC profile while faac supported more.

How popular are, say, hardware HE-AAC decoders out there? I have no
idea. And I also don't know how much coverage for the Main profile there is
out there...

I can try some audio on a Chinese (super small) settop box that I have, and
on my N900. I seem to remember that Apple claims that the iPod (at least
mine) only supports LC AAC profile.

I have never tried an AAC file with Parametric Stereo or with SBR.

 Creating a wrapper library that claims to be faac but does not support
 these features sounds like a bad idea.

Perhaps not a drop-in replacement, but an alternative implementation with a
different name?


Regards,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: How about: faac compatibility library using vo-aacenc

2012-06-04 Thread Fabian Greffrath

Am 27.05.2012 23:25, schrieb Fabian Greffrath:

Please share your opinions and ideas!


Such a bad idea that noone bothers to reply?

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


Re: How about: faac compatibility library using vo-aacenc

2012-06-04 Thread Sebastian Dröge
On Mo, 2012-06-04 at 11:11 +0200, Fabian Greffrath wrote:
 Am 27.05.2012 23:25, schrieb Fabian Greffrath:
  Please share your opinions and ideas!
 
 Such a bad idea that noone bothers to reply?

Last time I checked vo-aacenc did not support more than 2 channels and
also only the low-complexity AAC profile while faac supported more.

Creating a wrapper library that claims to be faac but does not support
these features sounds like a bad idea.


signature.asc
Description: This is a digitally signed message part
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

How about: faac compatibility library using vo-aacenc

2012-05-27 Thread Fabian Greffrath
Hi all,

I am thinking about this idea for quite some time but never got as far as
actually implementing it.

Do you think it is possible / feasible to develop a library that provides
the libfaac API but uses vo-aacenc for the actual encoding? This would
help applications that unconditionally depend on libfaac, e.g. handbrake,
to make it nito Debian until they are cleanly ported either directly to
vo-aacenc or to only conditionally depend on libfaac.

Is there anyone on this list who has experiences in this kind of
compatibility APIs or a concrete idea of how an implementation could look
like? For example, what to do if features of libfaac are requested that
are not yet implemented by vo-aacenc, Warn or Abort?

Please share your opinions and ideas!

Kind regards,
 - Fabian


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers