UdpSrc: streaming stopped, reason not-negotiated (-4)

[Jochen Jung]

Hello Bruce,


Thanks for your reply. Demultiplexing on the receiving end did the trick.
I'm using a "rtpptdemux" now instead of the "tee". The pads are added
dynamically and linked in the callback.

Thanks again for the tipp!


Regards Jochen Jung

On Thu, Aug 17, 2023 at 10:38 PM Bruce Clay via gstreamer-devel <
gstreamer-devel at lists.freedesktop.org> wrote:

> Although UDP is connectionless I don't think you can have two apps /
> streams going to the same port.  The data needs to be multiplexed on the
> source end then demultiplexed on the receiving end
>
> On Thu, Aug 17, 2023 at 10:42 AM Jochen Jung via gstreamer-devel <
> gstreamer-devel at lists.freedesktop.org> wrote:
>
>> Hello gstreamer developers,
>>
>>
>> I have a problem with the UdpSrc. My application is supposed to process
>> live audio(i.e. PCMU) and dtmf(TELEPHONE-EVENT). Both are rtp messages sent
>> to the same port.
>>
>> With debug enabled the UdpSrc posts a warning: streaming stopped, reason
>> not-negotiated (-4).
>>
>> I have my pipeline converted from dot to pdf and attached to this mail.
>>
>> Is it even possible to use the UdpSrc this way, having caps of pcmu and
>> telephone event?
>> Is my general concept to process audio/dtmf correct?
>>
>> Any ideas are appreciated.
>>
>>
>> Regards Jochen Jung
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230818/94b5a840/attachment.htm>