[FFmpeg-devel] One pass volume normalization (ebur128)

[Nicolas George]

Le nonidi 29 messidor, an CCXXI, Jan Ehrhardt a écrit :
> To answer my own question: Yes, that is possible. Since Nicolas
> problably does not want to tamper with volumedetect, I created a clone
> called af_volumeinject.c. See below.

I consider this very bad design. I already explained why I think this is bad
design from the result point of view, but you are of course free to keep it
in your software.

From ffmpeg point of view, I consider this bad design for the following
reasons:

* Two filters with almost identical features and no good reason to separate
  them (there is a good reason to have ebur128 and volumedetect: correctness
  vs. speed).

* Exposing intermediate values that have no relevancy whatsoever. The final
  results of volumedetect are already quite dubious as volume measurements,
  but at least they have a clear mathematical meaning. The intermediate
  values are just random excerpts taken at instants decided by whatever
  framing caused by previous filters.

* Adding a feature to suit a very personal and specific need.

IMHO, the correct design for solving this issue would require some or all
the following points:

* Dynamic expression evaluation for the volume filter. IIRC, Stefano had a
  patch that was pretty good; in fact, I thought it was already applied
  since a long time ago. The expression should be able to reference
  metatdata (at least one item).

* A filter to smooth a metadata value over time, so that r128.M can be
  turned into something suitable for volume normalization.

* A switch to volumedetect to inject as metadata the momentary RMS of the
  signal over a configurable frame, to use in place of r128.M and trade
  correctness for speed.

* A switch to volumedetect to inject as metadata the final results (on a
  dummy final frame maybe?).

* A clean way for filters to report information to the outside world.
  Hopefully, usable for structured information (porting ffprobe's printers),
  but just flat would already be nice (maybe extending the ffmetadata to
  dump per-frame metadata?).

* A scriptable filter capable of waiting the final frame on one of its
  inputs and using the metadata in it to send a command to a volume filter.

Some of these are fairly easy, other are quite hard, and some pose problems
of design decisions rather than implementation. Anyone should feel free to
submit patches implementing any of these points.

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/20130717/a873ec32/attachment.asc>