rtspsrc retrieves frames from another multicast stream
Describe your issue
I am currently in the process of bumping GStreamer to 1.22.9 in my solution. When using an rtspsrc pipeline to a multicast stream, the frames I receive are from another multicast stream. Both streams come from the same media gateway.
Expected Behavior
I expected both pipelines to retrieve frames from the corresponding stream. The pipelines are:
/usr/bin/gst-launch-1.0 rtspsrc location=$RTSP latency=20000 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! jpegenc ! multifilesink location="frame%05d.jpg"
with RTSP
being the RTSP link.
Observed Behavior
The pipeline running on rtsp://A.B.C.D:1234/camera01
corrrectly works.
The pipeline running on rtsp://A.B.C.D:1234/camera02
retrieves frames from the camera01
stream.
Setup
- Operating System: Linux
- Device: Docker container
- GStreamer Version: 1.22.9
-
Command line:
/usr/bin/gst-launch-1.0 rtspsrc location=$RTSP latency=20000 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! jpegenc ! multifilesink location="frame%05d.jpg"
Steps to reproduce the bug
Here's the Dockerfile used to build GStreamer:
# Taken from https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3202
FROM ubuntu:22.04
# Setting bash as the default shell in this container
SHELL ["/bin/bash", "-c"]
# Environment variable to configure timezone
ENV TZ=Etc/UTC \
GSTREAMER_VERSION=1.22.9
WORKDIR /tmp/workdir
RUN apt update \
&& apt install -y tzdata \
&& rm -rf /var/lib/apt/lists/*
RUN apt update \
&& apt install -y \
autoconf \
build-essential \
cmake \
curl \
dvb-apps \
fonts-open-sans \
g++ \
git \
liba52-0.7.4-dev \
libaom-dev \
libasound2-dev \
libass-dev \
libavc1394-dev \
libavcodec-dev \
libavdevice-dev \
libavformat-dev \
libavutil-dev \
libcdio-cdda-dev \
libcdio-dev \
libcdio-paranoia-dev \
libdrm-dev \
libfaad-dev \
libfdk-aac-dev \
libfreetype6-dev \
libgl1-mesa-dev \
libiec61883-dev \
libjack-dev \
libjpeg62-dev \
libmad0-dev \
libmp3lame-dev \
libogg-dev \
libopenal-dev \
libopencore-amrnb-dev \
libopencore-amrwb-dev \
libopus-dev \
libpng-dev \
libpulse-dev \
libraw1394-dev \
librtmp-dev \
libsdl2-dev \
libsoup2.4-dev \
libsrt-openssl-dev \
libssl-dev \
libswscale-dev \
libtheora-dev \
libtool \
libvorbis-dev \
libvpx-dev \
libwebp-dev \
libx264-dev \
libx265-dev \
libxcb-shape0-dev \
libxcb-shm0-dev \
libxcb-xfixes0-dev \
libxv-dev \
libxvidcore-dev \
mesa-utils \
pkg-config \
scons \
wget \
x11proto-gl-dev \
x11proto-video-dev \
yasm \
zlib1g-dev \
&& rm -rf /var/lib/apt/lists/*
ENV LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64
RUN apt update \
&& apt remove -y \
meson \
&& apt install -y \
python3-pip \
flex \
bison \
&& python3 -m pip install meson ninja tomli \
&& rm -rf /var/lib/apt/lists/*
###################################################################################################
# GStreamer clone
RUN git clone --depth 1 --branch ${GSTREAMER_VERSION} https://github.com/GStreamer/gstreamer.git
# GStreamer build
RUN cd /tmp/workdir/gstreamer \
&& meson setup --wipe \
-Dlibav=enabled \
-Dgood=enabled \
-Dbad=enabled \
-Dugly=enabled \
-Dgpl=enabled \
--buildtype release \
builddir \
&& meson compile -C builddir \
&& cd builddir \
&& meson install \
&& ldconfig \
&& cd /tmp/workdir \
&& rm -rf gstreamer
Build the image and run a container with --network host
to access multicast streams.
Running the gst-launch command on both streams should reproduce the bug.
How reproducible is the bug?
Always once we're in such a setup
Additional Information
With GStreamer 1.18.4, there is no such problem