rtpst2022-1-fecdec rtp extension problems
Describe your issue
When using RTP header extension, the rtpst2022-1-fecdec
is throwing around GStreamer-RTP-CRITICAL warning "gst_rtp_buffer_unmap: assertion 'rtp->buffer != NULL' failed".
The issue probably stems that the call on line 480 of gstrtpst2022-1-fecdec.c (xor_items
) fails, but the result is not checked (thus the rtp object is bad).
The failing assertionif (G_UNLIKELY (rtp->map[1].size < extlen))
in gstrtpbuffer.c line 392.
My guess is that this comparison actually is done on xored data, and thus fails randomly (as sometimes the xored data doesn't break the condition).
Not sure what are the implications of the bug, but since there is store_media_item
on invalid I would expect there would be some.
Expected Behavior
The rtpst2022-1-fecdec
handles the RTP data with extensions correctly.
Observed Behavior
FEC recovery seemed to be degraded, when using netsim.
Setup
- Operating System: Windows, Ubuntu
- Device: Bug is not device specific. Happens on my work desktop and home desktop.
- GStreamer Version: The bug is present on the version distributed by Ubuntu 22 (as tested in work) and also 41f478e9, which I used for debugging and this report
- Command line: N/A
Steps to reproduce the bug
The RTP packet needs to have an extension. Something like. Beware that not all extension data fails (check description of the bug)
#pragma pack(push, 1)
struct Test{
uint64_t a;
uint64_t b;
};
#pragma pack(pop)
Test data{};
data.a = SOMETHING_RANDOM;
data.b = SOMETHING_RANDOM2;
gst_rtp_buffer_add_extension_twobytes_header(&rtp, 0, FANCY_EXTENSION_ID, &data,
sizeof(Test));
edit:
Patch with broken test tried at 41f478e9
How I tested the bug
meson test -C builddir --suite gst-plugins-good elements_rtpst2022_1_fecdec
cat PATH_TO\gstreamer\builddir\meson-logs\testlog.txt
Content shows
How reproducible is the bug?
Happens often enough. Perhaps calling the xor_items
with mocked data is enough to reproduce.
Screenshots if relevant
Callstack:
Condition for failing packets:
This indicates that the buffer failed the comparison in gst_rtp_buffer_map. To check the flow in the Visual Studio it's possible to "Set next statement" in debugger to line 480 to see how exactly it fails.