Capsfilter causes problems in master

[Matej Knopp]

Small update, this is what seems to be happening:

audioconvert asks capsfilter for buffer
(note that at this point audioconvert seems to have proper caps - the
buffer caps intersected with caps on capsfilter)

the capsfilter however ignores the caps that audioconvert requested
and uses caps that it suggested itself after setting the "caps"
property on it.

Stack trace:

gst_pad_accept_caps (audioresample) ***
gst_base_trasnform_find_transform (capsfilter)
gst_base_transform_buffer_alloc (capsfilter)
gst_pad_buffer_alloc_unchecked (capsfilter)
gst_pad_alloc_buffer_full (audioconvert)
gst_pad_alloc_buffer (audioconvert)

*** this is where the warning happens as capsfilter tries to set the
filter caps on audio resample - which of course can't work because the
caps only contain certain properties (i.e. no rate).

So while I understand what is going on I don't know why this happens
now and didn't happen before. Is this correct behavior?

-Matej

On Fri, Oct 7, 2011 at 5:41 AM, Matej Knopp <matej.knopp at inmethod.com> wrote:
> Hi,
>
> I updated gstreamer today and I'm having weird issue when using capsfilter.
>
> I have following pipeline
>
> audioconvert -> capsfilter -> audioresample
>
> I set the following caps on caps filter:
> audio/x-raw-int, endianness=(int)1234,signed=(boolean)true,
> width=(int)16, depth=(int)16,
> channels=(int)2,channel-positions=(GstAudioChannelPosition)<
> GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT,
> GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT >
> (note that there is no audiorate)
>
> and I get the following warning:
> GStreamer-WARNING **: pad audioresample0:sink accepted caps
> audio/x-raw-int, endianness=(int)1234, signed=(boolean)true,
> width=(int)16, depth=(int)16, channels=(int)2,
> channel-positions=(GstAudioChannelPosition)<
> GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT,
> GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT > although they are not a
> subset of its caps audio/x-raw-int, endianness=(int)1234,
> signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int)48000….
> (because there is no rate set in caps; The rate is later of course set
> on buffer passed to elements)
>
> What happens is that the exact same caps as I set on capsfilter is
> also set on the downstream element sink. I don't understand why this
> happens suddenly.The caps is supposed to filter format of the upstream
> element, so why is it being sent downstream?
>
> Can anyone clarify this behavior?
>
> Cheers,
> Matej
>