[FFmpeg-devel] WIP: Loudness analysis filter with EBU R.128

[Marton Balint]

On Sun, 16 Sep 2012, Clément Bœsch wrote:

> Hi folks,
>
> First, I'm sorry it's again a WIP... I again need some comments to finalize it
> properly.
>
> The main point of this filter is to graph the loudness (related:
> http://tech.ebu.ch/loudness, https://en.wikipedia.org/wiki/Loudness_war). As a
> consequence, a video output is available, but is optional: at some point this
> filter could be used just to inject the loudness metadata in the filtergraph
> for further processing (like normalization), and thus the video output wouldn't
> be required. Concerning the audio, it's passed through unchanged to the next
> filter in both cases (because you likely want to hear what's being graph in
> real time, and it would be simpler to have a "ebur128,normalize" filtergraph
> than splitting the audio).

Great job! I had something similar in mind, but never had the time to 
implement it.

>
> Preview:
>
>    ./ffmpeg -nostats -i ~/ebur128/samples/seq-3341-2011-8_seq-3342-6-24bit-v02.wav -filter_complex ebur128=video=1 -y loudness.webm
>    => http://lucy.pkh.me/loudness.webm
>
> There is one main problem I still can't figure out: there are some A/V sync
> issues with ffplay (but not with ffmpeg as shown in the above loudness.webm
> output):
>
>    ./ffplay -f lavfi -i "amovie=input.mp3,ebur128=video=1 [out0][out1]
>
> I'm not sure where the problem is, but since no real-time is possible with the
> filter at the moment because of this issue.

I just posted a patch that should fix the ffplay issue.

>
> Just so things are clear, here is how audio and video are pushed in the ebur128
> filter:
>
>    - input is always 48kHz
>    - every 100ms (4800 samples) a video frame is pushed (within
>      filter_samples() callback), with pts computed based on insamples->pts and
>      the number of insamples processed
>    - at the end of the filter_samples() call, the insamples are sent to the
>      next filter
>
> Concerning the possible improvements on the filter, it should be stated in the
> commit description, so feel free to comment there. I also need to do some
> extended testing to check if the results are actually correct.
>
> About the first patch of the patch set, it moves the xGA stuff to lavu so I can
> use it in the filter instead of depending on freetype and stuff (it really is
> way more simpler in this context). Comments are welcome about how to expose
> this API in its best shape (see commit description).
>

Regards,
Marton