[FFmpeg-devel] [PATCH] Dolby Digital dynamic range compression (drc_scale) is now 0 by default
madshi at gmail.com
Mon Mar 30 11:54:47 CEST 2015
> From: "Kieran Kunhya" <kierank at obe.tv>
> To: "Wiebe Cazemier" <wiebe at halfgaar.net>
> Sent: Monday, 30 March, 2015 3:43:42 AM
> Subject: Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range
compression (drc_scale) is now 0 by default
> It is not an option and I quote ETSI 102 366:
> "Therefore, the AC-3 decoder shall, by default, implement the
> compression characteristic indicated by the dynrng values in the data
> stream. AC-3 decoders may optionally allow listener control over the
> use of the dynrng values, so that the listener may select full or
> partial dynamic range reproduction."
Let me ask you: The DVD and Blu-Ray specs require that a DVD/Blu-Ray player
not allow the user to skip forced video parts (like anti-piracy clips or
sometimes even trailers). So since the spec says so, we should make sure
that all open source media players also follow the spec to the letter and
not allow users to skip forced video clips? Is that truly your opinion? And
if the spec asks you to shoot yourself in the foot, you do that, too?
How about using some common sense: What should have priority? The best user
experience? Or following some stupid instructions in a spec? As I said
before, the only situation where the default value matters (and we're only
asking to change the default value, not to remove the ability to apply
dynamic range compression altogether) is when the software using ffmpeg is
not aware that there is such a thing as the drc_scale option. In this
situation of course you can blame the software. But the end result is that
the end user experience will suffer, because ffmpeg will output subpar
quality in that situation. What good is that for anybody?
What do you think would happen if we started a vote like the following:
1) Should ffmpeg output reduced (range compressed) audio quality by
default, because the spec says so?
2) Should ffmpeg output full (range) quality by default, unless the
software asks ffmpeg to do otherwise?
How many users or devs would vote for 1) or 2)?
And you didn't answer the question I asked before: Why would only AC3 have
range compression on by default? Why not any other codec? What is the sense
in that?? Are you saying that laptop speakers are not able to play full
range AC3 tracks, but that they *are* able to play full range TrueHD
tracks? If you truly believe that range compression should be on by
default, then you should be consistent about it, and ask for range
compression to be enabled by default for all other audio decoders, too.
We're intelligent beings, we don't have to blindly follow everything some
stupid spec says.
Best regards, Mathias.
2015-03-30 9:38 GMT+02:00 Wiebe Cazemier <wiebe at halfgaar.net>:
> ----- Original Message -----
> > From: "Kieran Kunhya" <kierank at obe.tv>
> > To: "Wiebe Cazemier" <wiebe at halfgaar.net>
> > Sent: Monday, 30 March, 2015 3:43:42 AM
> > Subject: Re: [FFmpeg-devel] [PATCH] Dolby Digital dynamic range
> compression (drc_scale) is now 0 by default
> > > It's in the spec as an *option*, to cater to those who have bad sound
> > > systems. If ffmpeg already applies DRC, and software using ffmpeg
> > > set 'drc_scale', it's no longer an option, it becomes mandatory. That's
> > > the issue.
> > It is not an option and I quote ETSI 102 366:
> > "Therefore, the AC-3 decoder shall, by default, implement the
> > compression characteristic indicated by the dynrng values in the data
> > stream. AC-3 decoders may optionally allow listener control over the
> > use of the dynrng values, so that the listener may select full or
> > partial dynamic range reproduction."
> > If an application doesn't want to expose drc settings then that's
> > their problem. FFmpeg does the right thing and lets you turn it off if
> > you wish.
> > Kieran
> (can you reply-all, so that your reply goes to the list?)
> If you say "it's not an option", that's putting it harder than the spec
> say. Dolby engineers never meant AC3 audio to be played compressed
> everywhere, and that's what we're seeing happening.
> Also, I feel that the word 'decoder' in your quote is written in a time
> where it had a different context and that quote has to be interpreted that
> way. Open source software libraries weren't available at that point, and a
> decoder was a piece of hardware, or a chip embedded in something. Sure, you
> don't have to allow the user to control it when you embed an AC3 decoder in
> your budget TV so ATSC demanding that you do would be silly here, but all
> high end receivers I know, do allow you to set the option. Now that we do
> have a library that people can use, an honest mistake to forget to
> implement it turns into something that they probably didn't intend. As
> proven by the Kodi developer denying that they applied DRC.
> I think we have to consider user experience, and it's great when they can
> control it, but we're getting the situation where everybody gets it (yet
> only for AC3), whether they want to or not. That automatically crosses off
> Kodi and VLC (for example) for use in high quality sound reproduction. And
> the bad thing is, they may not even know it...
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel