[FFmpeg-devel] [PATCH] lavc/ac3dec: disable DRC by default

[Derek Buitenhuis]

On 01/02/2020 21:03, rcombs wrote:
> 
>> If "I don't agree with the spec" or "this spec does something stupid" were valid
>> arguments, we may as well not have specs at all, and FFmpeg would have a lot more
>> garbage in it. You can write at length why you think it's bad, but that does not
>> negeate the fact that it's the spec,
> 
> I'm not sure why the spec should have any bearing on the defaults of configurable options, particularly when those defaults result in unexpected behavior that's unlike that used for any other codec.

Because it's the spec, and it defines that. It is the source of truth,
and, in my opinion, the expected default behavior as a result.

>> and the defacto way to handle decoding AC-3.
> 
> Is it, though? My understanding is that AV receivers usually only enable AC3 DRC in "night mode" or the like, and few even provide a fully-tunable setting for it. Apple's decoder in AudioToolbox (implemented on top of Dolby's) doesn't provide the feature at all (I haven't checked what Win32 Media Foundation does yet). So where does this "de facto" situation come from, other than lavc itself?

Because the spec defines what is de facto - it is what defines what AC-3 *is*.
You are choosing to ignore it here because you don't like what's in it.

I am of the opinion that a spec is better than a survey of a one software decoder
(not endorsed or acknowledged by Dolby afaik), and some unconfirmed info on some
recievers.

Is the spec dumb? Yeah probably, but lots of specs have dumb stuff in them. But
we follow them - which is the entire point of a spec.

> Meanwhile, Dolby's own decoder applies digital dialog normalization by default (contrary to how the spec says it should be applied downstream), and I haven't seen anyone arguing that lavc should do that.

Own decoder from where? Is it officially Dolby branded, or is this Apple again?

> Additionally, TrueHD has a very similar DRC feature that lavc doesn't support whatsoever, and nobody seems to mind.

Missing support in another decoder is not a good argument in favour or changing
behavior in one that is not missing support.

(As an aside, I have heard this used as an argument against using FFmpeg's
TrueHD decoder in the past, in Profession Broadcast Vendor Trade Shows(TM))

> One other thing I neglected to mention in the commit message: the actual audio encoded in an (E)AC3 track often has levels similar to those of a track in another codec (PCM, AAC, etc) from the same or other sources, but sounds very different when both are decoded with lavc. For instance, Netflix's EAC3 sounds about the same as BD audio of the same content when decoded without DRC, but in lavc-based players by default, it sounds, well... compressed. This had led to an impression in the anime community that Netflix applies excessive DRC to their EAC3 streams at encode-time, and thus that those streams were low-quality and should be avoided.

Netflix is the origin of that audio, not the master. I suspect it's a byproduct of how they
transcode, rather than inherent to the show/BD/master/whatever itself. I don't think it's
a good argument in favour of changing the default behavior to be contrary to the spec,
but YMMV, I'm only one person. If people on the list decide they prefer it that way, then
it'll be that way - this is just my opinion as an API user and someone who has dealt with
too much vendor FUD.

- Derek