[MPlayer-dev-eng] AAC decoding is out of sync

[Grozdan]

On Fri, Apr 16, 2010 at 2:09 PM, compn <tempn at twmi.rr.com> wrote:
> On Fri, 16 Apr 2010 12:11:54 +0200, Grozdan wrote:
>>On Fri, Apr 16, 2010 at 6:58 AM, RC <cooleyr at gmail.com> wrote:
>>> On Thu, 15 Apr 2010 18:57:32 +0200
>>> Grozdan <neutrino8 at gmail.com> wrote:
>>>
>>>> I think it was a bad call to add ffaac as default decoder for AAC as
>>>> it tends to screw up in a lot of cases. I prefer FAAD over it anytime.
>>>
>>> The MPlayer project is perpetually in "testing".  There is no stable
>>> branch.  Faster codecs have always gotten precidence over more reliable
>>> ones, and setting somewhat buggy codecs as the default has long been the
>>> method to get them tested.  In short, it's not an argument you can win.
>>
>>I'm not looking to win arguments here. Just pointed out that IMO it
>>was a bit too soon that ffaac was made default and from a user's
>>perspective who just wants to throw a file at it and watch it, he
>>doesn't really care which one is default as long at it works. There
>>are much more users who are not interested in testing than there are
>>who want to test or trying for hours to find a solution to get it work
>>(and get frustrated along the way, some eventually giving up). And
>>last time I checked, peeps involved in mplayer & ffmpeg already do a
>>good amount of testing.
>
> we got 4+ bugreports out of that simple change already. its only done
> in svn, not an actual release. and that user wanted to watch matrix 3
> anyways. i'd consider it a feature not to hear the dialog in that movie.
>
> but yes, ordinary svn users were inconvenienced for a month while the
> change was in effect. this is how mplayer and ffmpeg have worked
> since the projects started.
>
> mplayer/ffmpeg devs test all files we can get a hold of. this was a
> prerequisite of committing the aac decoder in the first place. we
> force users to test files because there is no way we can check every
> file ever made ourselves.
>
> an automated testing script (like ffmpeg's fate) would be very useful to
> mplayer in checking for regressions. but mplayer has a very small
> amount of developers, so i dont think it will get done without outside
> help.

No, no, you're right (not really arguing with that). What I tried to
say is that such decisions should be more obvious/visible to the end
user. There's no mention in the Changelog (or anywhere else besides ML
which by a lot of users doesn't get read) that two audio decoders have
been switched (a52 & faad), nor is there mention that something may be
missing or not optimal/cause problems. MPlayer/ffmpeg devs may very
well know that f.ex ffaac has problems with some files, but the end
user doesn't know that nor is aware in advance so when he sees these
problems, I can understand end user's frustrations and the time spent
trying to figure out why his previous mplayer had no problems but
suddenly with the new one, it has, and this combined with not
mentioning such switching of decoders, makes it harder for end user's
to know what causes it or where to look for, so they get frustrated.

>
>>Only yesterday we had a pretty frustrated user come to #mplayer asking
>>why a52drc no longer works as he wasn't aware that mplayer has
>
> thats a good point. maybe there should be some kind of message like
> 'warning, a52drc works with afm liba52 but decoder is afm ffmpeg' or we
> should make a52drc work with the ffac3.
>
>>switched to ffac3 which although has a drc option, it doesn't get
>>exposed to mplayer like the one from liba52
>
> there is a patch here for ffac3 drc:
> http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1607
>
> how come no one suggested he use -ac faad or -af pan to mix the 6
> channels to 2? i suggested -af hrtf and user reported that it helped,
> but caused some buzzing noise (an hrtf bug? needs to be reported.)

I did. Even redirected him to #mplayerdev as I thought it was Diego
(who at that time was there) made the decision to make ffac3 default,
but it turned out it was Reimar instead. Uoti mentioned that ffac3 has
drc, but he was a bit unsure how to expose it to mplayer (for more
details about that, ask him)

>
> i know you just want to throw a file at it without messing with command
> lines, but how do you think we got so many files working without extra
> options in the first place?
>
> ac3 dialog is known to be at lower volume than all other codecs.
> http://roundup.ffmpeg.org/issue1153
> it happens with faad too. faad does downmixing and you dont notice it
> as much.
>
> -compn
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng