rtp_payloading: Tests succeed although they actually fail
Let's take this as an example
$ GST_CHECKS=rtp_vorbis meson test --suite gst-plugins-good elements_rtp_payloading
Also happens with
rtp_mp4v at least. If we look in the logs we see
0:00:00.583530701 753358 0x556af2f48590 WARN GST_CAPS gstpad.c:3230:gst_pad_query_accept_caps_default:<rtpvorbisdepay0:sink> caps: application/x-rtp, media=(string)audio, payload=(int)96, encoding-name=(string)VORBIS, ssrc=(uint)922420776, timestamp-offset=(uint)2224758342, seqnum-offset=(uint)2906 were not compatible with: application/x-rtp, media=(string)audio, payload=(int)96, encoding-name=(string)VORBIS, ssrc=(uint)922420776, timestamp-offset=(uint)2224758342, seqnum-offset=(uint)2906, clock-rate=(int)[ 1, 2147483647 ] [...] 0:00:00.583758172 753358 0x556af2f48590 DEBUG GST_SCHEDULING gstpad.c:4401:gst_pad_chain_data_unchecked:<rtpvorbispay0:sink> called chainfunction &0x7f81bded6f90 with buffer 0x556af306c240, returned ok [...] 0:00:00.584860036 753358 0x556af2f48590 DEBUG GST_EVENT gstpad.c:5770:gst_pad_send_event_unchecked:<fakesink0:sink> have event type eos event: 0x556af30616b0, time 99:99:99.999999999, seq-num 19, (NULL)
The depayloader does not accept the caps of the payloader because they contain no
clock-rate field. However this does not cause the test to fail because the payloader does not even try to output a buffer, it only consumes the buffer and happily returns. Then the app source is done and sends EOS, and it gets send through until the sink.
There is no dataflow happening between the payloader and the sink at all in this test.
This probably happens because the data passed into the payloader is invalid.