[FFmpeg-devel] [PATCH] news: add a news entry for the AAC encoder experimental flag removal

Ganesh Ajjanagadde gajjanag at mit.edu
Sat Dec 5 21:33:44 CET 2015


On Sat, Dec 5, 2015 at 3:27 PM, Rostislav Pehlivanov
<atomnuker at gmail.com> wrote:
> Sorry, sent out this email to Ganesh only at first. Posting it to the ML
> now.
>
>>Consider adding a link to such tests/how to verify this.
> Subjective tests. I did try to compare them using an SSIM audio filter
> (based on a journal paper) I wrote for lavfi a few months ago but I gave up.
> Spoke with the Opus guys who outright told me that it makes no sense to use
> SSIM and that basically all of the tests done while developing Opus were
> subjective. So I never got the filter merged because it would have been a
> pointless statistic.

Thanks for the clarification.

Frankly, I never buy PSNR/SSIM for audio and video myself: it is very
clear that they were designed as mathematically convenient due to
relations to Euclidean norms and hence to allow possible integration
into the standard L_2 theory. Users may or may not care depending on
their background or personal taste. Of course, it does not mean they
are useless, since they can give automated, reproducible tests for
regression like FATE, and in the absence of anything better, they
stand. Or in other words, the actual choice I find arbitrary.

>
>>Also list
>>what you are comparing to.
> Speaking in general and for libfdk_aac in specific. I am not going to
> mention its name in the blog post.
>
>>Maybe even a pic with performance/quality
>>benchmarks.
> I don't see pictures in any news and I wouldn't want to break that
> tradition.
> Encoding performance is twice as slow compared to libfdk_aac. Which is still
> 12x realtime on my poor Celeron B820. In the grand scheme of things this is
> insignificant.

Maybe, maybe not. I can't judge if that perf number is important.
Nevertheless, I personally always highly value complete honesty wrt to
public facing announcements, academic papers, etc. That honesty
includes listing pros and cons.

As for the pic: I don't see why we can't break with tradition :).
FFmpeg is after all a multimedia framework. According to your claim
above, such a pic is not easy due to subjective nature, so ok.

>
>>In short, please add some more detail at your discretion.
> As I said earlier, this is not something I or anyone else can show nor prove
> to be valid in general for all people for all audio files. There is just a
> general agreement among the encoder developers that yes, for some samples
> the encoder sounds better at 128kbps and yes, for some samples it sounds
> worse. But the prevalent idea is that the encoder is transparent for most
> files encoded at 128kbps, which is the de-facto standard CBR bitrate for
> AAC.
> But don't take my word for it. Test it yourself.

No problem, I trust you :) - I don't use AAC myself, and am not an
audiophile to really judge.

>
>>Did not know feedback also goes on the bug tracker. I don't really
>>know, maybe "feedback via IRC/ffmpeg-devel/private email" (pick
>>whatever subset you want)?
> There's a large trac ticket with over 450 replies. That's where the main
> source of external feedback comes from. Mainly from Kamedo2 whom I credited.
>
>>Consider refining the Changelog entry from "- extensive native AAC
>>encoder improvements" to "extensive native AAC encoder improvements
>>and removal of its experimental flag".
> Did that slightly before I sent the mail.
>
>>Anyway, great work, thanks!
>
> On 5 December 2015 at 19:29, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>>
>> On Sat, Dec 5, 2015 at 2:14 PM, Rostislav Pehlivanov
>> <atomnuker at gmail.com> wrote:
>> > Signed-off-by: Rostislav Pehlivanov <atomnuker at gmail.com>
>> > ---
>> >  src/index | 21 +++++++++++++++++++++
>> >  1 file changed, 21 insertions(+)
>> >
>> > diff --git a/src/index b/src/index
>> > index d1d4a58..0c54046 100644
>> > --- a/src/index
>> > +++ b/src/index
>> > @@ -37,6 +37,27 @@
>> >      News
>> >    </h1>
>> >
>> > +  <a id="aac_encoder"></a><h3>The native FFmpeg encoder is out of
>> > experimental!</h3>
>> > +  <p>
>> > +    After seven years the native FFmpeg AAC encoder has had its
>> > experimental flag
>> > +    removed and declared as ready for use. Subjective quality tests put
>> > the
>> > +    encoder to be of equal or greater quality than most of the other
>> > encoders
>> > +    available to the public.
>>
>> Consider adding a link to such tests/how to verify this. Also list
>> what you are comparing to. Maybe even a pic with performance/quality
>> benchmarks.
>>
>> In short, please add some more detail at your discretion.
>>
>> > +  </p>
>> > +    Licensing has always been an issue with encoding AAC audio as most
>> > of the
>> > +    encoders have had a license making FFmpeg indistributable if
>> > compiled with
>> > +    support for them. The fact that there now exists a fully open and
>> > truly
>> > +    free AAC encoder integrated directly within the project means a lot
>> > to those
>> > +    who wish to use accepted and widespread standards.
>> > +  </p>
>> > +    The majority of the work done to bring the encoder up to quality
>> > was
>> > +    done by Claudio Freire and Rostislav Pehlivanov. Also thanks to
>> > +    <a href="http://d.hatena.ne.jp/kamedo2/">Kamedo2</a> who does
>> > comparisons
>> > +    and tests, the original authors and all past and current
>> > contributors to the
>> > +    encoder. Users are suggested and encouraged to use the encoder and
>> > provide
>> > +    feedback or breakage reports through our <a
>> > href="https://trac.ffmpeg.org/">bug tracker</a>.
>>
>> Did not know feedback also goes on the bug tracker. I don't really
>> know, maybe "feedback via IRC/ffmpeg-devel/private email" (pick
>> whatever subset you want)?
>>
>> Consider refining the Changelog entry from "- extensive native AAC
>> encoder improvements" to "extensive native AAC encoder improvements
>> and removal of its experimental flag".
>>
>> Anyway, great work, thanks!
>>
>> > +  </p>
>> > +
>> >    <a id="thanks_sponsor_0001"></a><h3>Telepoint & MediaHub are now
>> > supporting our project</h3>
>> >    <p>
>> >      A big thank you note goes to our newest supporters: MediaHub and
>> > Telepoint.
>> > --
>> > 2.6.2
>> >
>> > _______________________________________________
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel at ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>


More information about the ffmpeg-devel mailing list