gstreamer分析-rtp流的接收

Posted 2023-05-03

参考技术A  关于数据流的接收过程，[1]有很好的分析。这个问题，令人困惑，依然有些东西没有搞明白。gst_pad_start_task()创建任务，使得gst_base_src_loop()被循环调用。

 udosrc怎么同rtpbin关联起来呢？gst-lpugins-good/tests/examples/client-rtpaux.c下有个例子，有个图：

 udosrc和rtpbin都继承了element。gst_element_link_pads将两者连起来。

 rtpbin中的pad是如何接收数据呢？

gst_pad_push中调用的chainfun就是这个gst_rtp_session_chain_recv_rtp。
 接下来分析rtp数据流的处理，以on-feedback-rtcp这个类型的消息为例。

 前前后后一共浪费了六天时间，好奇心害死猫。以后应该研究一些数学密集型的程序，而不是逻辑密集型的程序。
 剧终。
[1] GStreamer插件架构简析

使用 gstreamer 播放传入的 RTP 视频流

【中文标题】使用 gstreamer 播放传入的 RTP 视频流

【英文标题】：Playing incoming RTP video stream with gstreamer

【发布时间】：2012-08-11 18:39:33

【问题描述】：

我找到了一个基于 gst-launch 的工作示例，用于通过 RTP 发送和接收视频流。我已将它们重写为 C。发件人工作正常，但收件人没有。我有 2 台计算机，A 和 B。当流式传输 B->A 时，它工作正常，但是当 A->B 时，B 没有显示流。流即将到达 B（使用 wireshark 检查）。能不能看一下代码，看看有没有我没发现的bug？

这是 gst-launch 应用程序：

VIDEO_CAPS="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H263-1998"
gst-launch-0.10 -v gstrtpbin name=rtpbin latency=100 \
    udpsrc caps=$VIDEO_CAPS port=5000 \
    ! rtpbin.recv_rtp_sink_0 rtpbin. \
    ! rtph263pdepay \
    ! ffdec_h263 \
    ! ffmpegcolorspace \
    ! autovideosink
    udpsrc port=5001 \
    ! rtpbin.recv_rtcp_sink_0 rtpbin.send_rtcp_src_0 \
    ! udpsink host=$1 port=5005 sync=false async=false

对应的 C 代码在 [1] 上，因为它很长。

[1]http://pastebin.com/54eHvZWH

【参考方案1】：

您没有连接到 rtpbin 中的 request-pt-map 信号，而是在 udpsrc 上设置了上限。一般的想法是 rtpbin 告诉您“嘿，我收到了一个新的有效载荷编号，我应该分配给它的上限是多少？”。然后，您提供现在直接在 udpsrc 上设置的上限（减去有效负载编号）。我不确定这是否会有所帮助，但这是你应该这样做的方式。使用 GST_DEBUG=*rtp*:5 运行接收器或许也能提供一些线索。