Я получаю два UDP-потока, синхронизированных по NTP-часам с использованием RTPBin, для приема моим собственным приложением с использованием двух appinks, как показано в приведенном ниже конвейере.Это отлично работает в 90% случаев, когда приложение запускается.
rtpbin name=rtpbin latency=80 \
udpsrc caps=\"application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264\" \
port=40322 ! rtpbin.recv_rtp_sink_0 \
rtpbin. ! rtph264depay ! queue ! avdec_h264 ! videoconvert ! video/x-raw,format=RGBA,width=1296,height=972 ! appsink name=appsink_0_left \
udpsrc port=40323 ! rtpbin.recv_rtcp_sink_0 \
udpsrc caps=\"application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264\" \
port=40320 ! rtpbin.recv_rtp_sink_1 \
rtpbin. ! rtph264depay ! avdec_h264 ! videoconvert ! video/x-raw,format=RGBA,width=1296,height=972 ! appsink name=appsink_1_right \
udpsrc port=40321 ! rtpbin.recv_rtcp_sink_1
Однако при выполнении иногда два сеанса rtpbin меняются местами, и appsink # 0 получает поток # 1 вместо потока # 0., и наоборот.Это происходит с, казалось бы, случайной частотой.Мое приложение использует стереофоническое отображение, поэтому важно, чтобы каждый appink получил поток с правильными номерами.
Теоретически каждый сеанс RTP нумеруется RTPBIN, а затем отправляется как recv_rtp_src_% u_% u_% u (гдепервый% u - номер сеанса) для rtph264depay.К сожалению, rec_rtp_src_% u_% u_% u генерируется динамически и, по-видимому, недоступен, и вы должны использовать RTPBin.который автоматически выбирает первый доступный поток с наименьшим номером, который является правильным в 90% случаев, но иногда неверным.
Есть ли способ выбрать, какой сеанс / поток RTP будет доставлен в какой приемник??В качестве альтернативы, есть ли другой способ получить два потока UDP, синхронизировать их и вывести их на правильные приемники?