On Wed, Apr 06, 2016 at 05:16:31PM +0200, Tobias Rapp wrote: > On 06.04.2016 17:02, Clément Bœsch wrote: > >On Wed, Apr 06, 2016 at 09:52:51AM -0500, Kyle Swanson wrote: > >>On Wed, Apr 6, 2016 at 12:45 AM, Clément Bœsch <u...@pkh.me> wrote: > >>>Mmh. That's nice and all but... why not use/adjust the native ebur128 > >>>filter we have instead of relying on an external library? > >>> > >>>[...] > >>> > >>>-- > >>>Clément B. > >> > >>This could be an option for the future. We'll need to break all the > >>EBU R128 logic out into utility functions > > > >why? what do you need exactly from the filter? The meta are exported in > >each audio frame. > > > >>and update it to use the newest version BS.1770 so it can be used by > >>both filters. Using libebur128 is a > >>good option because it is widely used, actively developed, and updated > >>whenever the spec changes. > > > >except it's an external dependency and we have code builtin available, > >doing the same thing, and with no open issue (afaik). > > From the top of my head libebur128 additionally supports sample-rates != > 48kHz
The standard is (was?) only defined for 48kHz, although the filters coefficients could be derivated for other frequencies. ff ebur128 could be adjusted for that. > and allows true-peak measurement (oversampling with the help of > libspeex-dsp). True peak is implemented in ebur128 (oversampling with the help of swresample). [...] -- Clément B.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
