[Bug 776413] flacenc: Wrong quality levels in GStreamer, level 9 doesn't exist in libflac

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Dec 23 11:44:43 UTC 2016


https://bugzilla.gnome.org/show_bug.cgi?id=776413

--- Comment #4 from Christian Stadelmann <gnome at genodeftest.de> ---
(In reply to Tim-Philipp Müller from comment #3)
> If it never worked, it's not really an API/ABI break :)

Ok, that's right.

> I'm just wondering if this is something that changed in libflac at some
> point or if we really had this wrong for almost 10 years without anyone
> noticing

I was wondering the same and had a look at libflac changelogs which didn't note
any changes in compression levels.

Anyway, libFLAC specifies
> A value larger than 8 will be treated as 8.

in
https://git.xiph.org/?p=flac.git;f=include/FLAC/stream_encoder.h;hb=HEAD#l811

so GStreamer is doing something differently weird. It seems that

GstFlacEncParams flacenc_params[] in
https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/flac/gstflacenc.c#n185
differs from Xiph's CompressionLevels compression_levels[]
https://git.xiph.org/?p=flac.git;f=src/libFLAC/stream_encoder.c;hb=HEAD#l102
shouldn't they be the same?

Should we request the CompressionLevels struct to be public?

For example: At compression level 7, GStreamer sets max_lpc_order=8 whereas
libFLAC sets it to 12. Also, FLAC__bool do_exhaustive_model_search is always
False, whereas the GStreamer implementation sets it to TRUE for level 7 to 9.
Other parameters differ too.

It looks like the author of GstFlacEnc just invented compression level 9, at
least that is what the parameters look like.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list