[FFmpeg-devel] [PATCH 2/2] lavfi/volume: support volume normalization through metadata.

[Nicolas George]

Le primidi 11 ventôse, an CCXXI, Clement Boesch a écrit :
> Do you mean something like "volume=@{metadata_key}" or I'm still in the
> fog?

Yes, exactly.

(Except connecting the frame metadata to the eval system would not be
completely trivial, but that is something that goes beyond volume
normalization: -vf facedetect,crop=150:200:@{face.x}-75:@{face.y}-100. For
now, just importing one metadata key designated by an option as an eval
variable would be enough I guess.)

> Yes, with an overlap of 100ms. The integrated loudness value provides
> interesting results here.

No, the integrated loudness is not suitable. Imagine you have a hour long
program at -25 dB and then a very loud two minutes long teaser at -18 dB:
when renormalizing, you want the teaser volume to be lowered, but its
loudness is completely drowned by the program itself in the integrated
loudness.

> I'm not sure that's really necessary; a symmetrical interval would mean
> you try to minimize punctual blasts, which is not desired (at least in
> what the authors of R128 were aiming), but I may be wrong.

I do not know what the R128 guys had in mind, but it seems obvious that the
interval must be somewhat symmetrical and have look-ahead. Otherwise, if the
volume increases suddenly, you will get the loud volume for a few instants
before the filter catches on.

And I am pretty sure it needs a typical reaction time between 1 second and 1
minute: below 1 second, it will start to give audible distortion, and beyond
1 minute it will not be able to react to short loudness changes, such as
commercials or jingles.

(The integrated loudness, unless I am mistaken, has a typical reaction time
that is equal to the duration of the data already processed: it will react
very fact in the beginning and very slowly at the end.)

> I'll resend a patchset soon, where the volume filter changes is more
> flexible and will allow you to experiment such symmetrical interval with
> another filter (volumedetect for instance). You should be able to hack
> into ebur128 as well to inject different info.

IMHO, you are currently working at cross-purpose with Stefano on af_volume:
one of you will lose a lot of time rebasing his patch on top of the other's
work at some point.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130301/6d54b32b/attachment.asc>