When got pipeline with some postprocessing, like this:
audio/x-raw S24_32LE —> audioconvert —> volume —> audioconvert —> alsasink {S16LE,S24_32LE}
I guess the audioconvert incorrectly picks format for the volume plugin and downgrades quality to S16LE. It seems like for some reason S16LE is first in othercaps
entering to the function gst_audio_convert_fixate_caps
and because of that, the result is not correct. I did some hotfix for my usecase but I am not sure of introducing any side effects.
This is graph of my pipeline simulated on PC.
And this is patch I made, that worked for me.
From 0af77af90074787e8a05afaeac9ae710b0c417d9 Mon Sep 17 00:00:00 2001
From: Michal Jenikovsky <michal.jenikovsky@streamunlimited.com>
Date: Mon, 26 Aug 2024 19:51:18 +0200
Subject: [PATCH] fixate_caps: simplify othercaps before intersection
This removes duplicates from processed caps and eliminates incorrect
picks of "preferred" caps.
Signed-off-by: Michal Jenikovsky <michal.jenikovsky@streamunlimited.com>
---
gst/audioconvert/gstaudioconvert.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gst/audioconvert/gstaudioconvert.c b/gst/audioconvert/gstaudioconvert.c
index d7f616b..84769fc 100644
--- a/gst/audioconvert/gstaudioconvert.c
+++ b/gst/audioconvert/gstaudioconvert.c
@@ -698,6 +698,8 @@ gst_audio_convert_fixate_caps (GstBaseTransform * base,
GstStructure *ins, *outs;
GstCaps *result;
+ othercaps = gst_caps_simplify (othercaps);
+
GST_DEBUG_OBJECT (base, "trying to fixate othercaps %" GST_PTR_FORMAT
" based on caps %" GST_PTR_FORMAT, othercaps, caps);
--
2.25.1
I think that simplifying othercaps
makes sense, because there is later code in gst_audio_convert_fixate_format
that picks most favorable format from array of formats, but the first item is only 1 caps structure with exact format set S16LE. And it gets picked, because later in code there is this outs = gst_caps_get_structure (result, 0);
.
So the patch should activate the logic in gst_audio_convert_fixate_format
and pick right format every time.