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