2

我有一个用 C++ 编码的管道，如下所示：

appsrc do-timestamp=TRUE is-live=TRUE caps=
“video/x-h264, stream-format=(string)byte-stream, alignment=(string)none, framerate=(fraction)0/1” min-latency=300000000 ! h264parse ! video/x-h264, stream-format=(string)avc, alignment=(string)au ! tee name=t \
t. ! queue ! valve drop=FALSE ! decodebin ! glupload ! glcolorconvert ! qtsink sync=FALSE \
t. ! queue ! valve drop=FALSE ! mp4mux reserved-max-duration=3600000000000 reserved-moov-update-period=10000000000 ! filesink sync=FALSE location=”....../out.mp4”

appsrc 将来自无人机的 USB 无线视频接收器的视频注入管道。

更多上下文：

  • USB 接收器硬件为我们提供了 512 字节的非时间戳原始 Annex-B h.264 视频块
  • 帧率应该是 60 fps，但实际上它很少跟上它并且取决于信号强度（因此 framerate=(fraction)0/1”，这就是 qtsink 和 filesink 都没有同步到管道的原因（同步=假））
  • 硬件引入了至少 300 毫秒的延迟，如 appsrc 中所设置
  • appsrc 自动为我的缓冲区添加时间戳 (do-timestamp=TRUE)
  • 我正在使用 mp4mux reserved-max-duration 和 reserved-moov-update-period 来防止应用程序崩溃破坏 mp4 文件
  • 我正在为 Android 使用 GStreamer 1.18.4

当无人机未在空中时，视频录制工作正常。但是当它起飞时，在大约 15 秒的正确视频录制后，mp4mux 元素失败并显示消息“<strong>Buffer has no PTS”。不幸的是，一些用户一直在报告这一点，但我无法重现它（因为它需要飞行我没有的无人机），这没有多大意义。到目前为止，我的猜测是，在那个特定时刻，无线视频链路中可能存在一些拥塞，并且某些视频数据包可能会延迟几毫秒，这可能会造成一些麻烦。

这是创建appsrc的（简化的）代码

   _pAppSrc = gst_element_factory_make("appsrc", "artosyn_source");
    gpointer pAppSrc = static_cast<gpointer>(_pAppSrc);

    // Retain one more ref, so the source is destroyed
    // in a controlled way
    gst_object_ref(_pAppSrc);

    pCaps = gst_caps_from_string("video/x-h264, stream-format=(string)byte-stream, alignment=none, framerate=(fraction)0/1"));
    g_object_set(G_OBJECT(pAppSrc), "caps", pCaps,
                                    "is-live", TRUE,
                                    "min-latency", G_GINT64_CONSTANT(300000000),
                                    "format", GST_FORMAT_TIME,
                                    "do-timestamp", TRUE,
                                    nullptr);

   _pBufferPool = gst_buffer_pool_new();

   pConfig = gst_buffer_pool_get_config (_pBufferPool);

   static const guint kBufferSize  = 512;
   static const guint kPoolSize    = 0x400000;
   static const guint kPoolSizeMax = 0x600000;

    qsizetype nBuffersMin = kPoolSize / kBufferSize;
    qsizetype nBuffersMax = kPoolSizeMax / kBufferSize;

    gst_buffer_pool_config_set_params(pConfig, pCaps, kBufferSize, nBuffersMin, nBuffersMax);

   gst_buffer_pool_set_config(_pBufferPool, pConfig);
   gst_buffer_pool_set_active(_pBufferPool, TRUE);

   gst_caps_unref(GST_CAPS(pCaps));

当一个新的缓冲区被 USB 驱动程序填满时，它会像这样被推送到管道中：

bool unref = false;

gst_buffer_unmap(b->pBuffer, &b->mapInfo);
gst_buffer_set_size(b->pBuffer, xfer.pXfer->actual_length);

if(result == LIBUSB_TRANSFER_COMPLETED)
{
    //-- DROP DATA IF NOT IN PLAYING STATE --
    GstState st, pend;
    GstStateChangeReturn scr = gst_element_get_state(GST_ELEMENT(_pAppSrc), &st, &pend, GST_CLOCK_TIME_NONE);
    Q_UNUSED(scr)
    bool drop = (st != GST_STATE_PLAYING);

    if(!drop)
    {
        GstFlowReturn ret = GST_FLOW_OK;

        // Push into pipeline
        ret = gst_app_src_push_buffer(GST_APP_SRC(_pAppSrc), b->pBuffer);

        if(ret != GST_FLOW_OK)
            qCDebug(MMCVideoLog()) << "Can't push buffer to the pipeline (" << ret << ")";
        else
            unref = false;  // Don't unref since gst_app_src_push_buffer() steals one reference and takes ownership
    }
} else if(result == LIBUSB_TRANSFER_CANCELLED)
{
    qCDebug(MMCVideoLog()) << "! Buffer canceled";
} else {
    qCDebug(MMCVideoLog()) << "? Buffer result = " << result;
}    

if(unref)
    gst_buffer_unref(b->pBuffer);

这是我从受影响的机器上从 Android logcat 得到的：

[07-22 18:37:45.753 17414:18734 E/QGroundControl]
VideoReceiverLog: GStreamer error: [element ' "mp4mux0" ']  Could not multiplex stream.

[07-22 18:37:45.753 17414:18734 E/QGroundControl]
VideoReceiverLog: Details:  ../gst/isomp4/gstqtmux.c(5010): gst_qt_mux_add_buffer (): /GstPipeline:receiver/GstBin:sinkbin/GstMP4Mux:mp4mux0:
Buffer has no PTS.

我试过的：

  • 将 GstBaseParser pts_interpolation 设置为 TRUE，并将 infer_ts 设置为 TRUE

所以我的问题是：

  • 你能看出我的代码有什么问题吗？我错过了什么？
  • 在找到真正原因之前，我可以依靠 matroskamux 暂时避免该问题吗？

编辑：我设法在“原位”复制它，同时使用连接到我的 tee 元件的接收垫的探针打印出每个缓冲区的 PTS 和 DTS，并发现问题缓冲区没有 DTS 和没有 PTS。也许我的 h264parse 或 capsfilter 在我的 appsrc 和我的 tee 之间做了一些讨厌的事情？

07-28 17:54:49.025  1932  2047 D : PTS:  295659241497 DTS:  295659241497
07-28 17:54:49.026  1932  2047 D : PTS:  295682488791 DTS:  295682488791
07-28 17:54:49.053  1932  2047 D : PTS:  295710463127 DTS:  295710463127
07-28 17:54:49.054  1932  2047 D : PTS:  18446744073709551615  DTS:  18446744073709551615
07-28 17:54:49.054  1932  2047 E : ************** NO PTS
07-28 17:54:49.054  1932  2047 E : ************** NO DTS
07-28 17:54:49.110  1932  2047 D : PTS:  295738607214 DTS:  295738607214
07-28 17:54:49.111  1932  2199 E : GStreamer error: [element ' "mp4mux1" ']  Could not multiplex stream.
07-28 17:54:49.111  1932  2199 E : Details:  ../gst/isomp4/gstqtmux.c(5010): gst_qt_mux_add_buffer (): /GstPipeline:receiver/GstBin:sinkbin/GstMP4Mux:mp4mux1:
07-28 17:54:49.111  1932  2199 E : Buffer has no PTS.

编辑 2：经过更多挖掘，我发现了更多线索：我编写了一些代码，将通过 USB 传来的每个视频数据包连同时间戳转储到二进制文件中，并使用播放器进行播放。然后我去现场让客户驾驶无人机，直到触发错误。这样我就有了一种随意重现错误的方法。

通过使用两个探针，一个连接到我的“appsrc”元素的“src”焊盘，一个连接到我的“tee”元素的“sink”焊盘，我打印了通过它们的每个数据包的 PTS 和 DTS。

以下是我的发现：

TL;DR：在某个（随机）点，即使 h264parse 被提供带时间戳的缓冲区，它也会输出一个没有 PTS 和 DTS 的缓冲区。

  • 产生我通过 USB 获得的流的硬件 h264 编码器插入没有 VUI 的 SPS NALS，并且"[parser] unable to compute timestamp: VUI not present"在将 h264parse 调试级别设置为 6 时出现很多这样的错误

  • “VUI 不存在”错误非常一致并且非常频繁地出现。大多数时候都没有注意到，因此我不是 100% 确定这是原因

  • 由于appsrc 推送的h264 缓冲区没有对齐，并且h264parse 输出的是au-aligned 缓冲区，因此appsrc 中的512 字节缓冲区数与h264parse 中的缓冲区数之间没有直接关系。因此，我相信可以相当肯定地说，appsrc 生成的时间戳与 h264parse 生成的时间戳之间没有直接关系。h264parse 必须重新计算它们。

  • 我的 h264 流非常简单：SPS->PPS->I-frame->(一些 P-frames)。没有 B 帧，每一帧都包含在一个大的脂肪片中（只有 1 个 NAL）。

所以，现在我试图在这两个选项之间进行选择：

  1. 每次检测到无 VUI 的 SPS 时，手动计算并插入带有 VUI 的假 SPS NAL。由于无线电信号强度（尽管它以 60fps 编码），流应该具有可变的帧速率，并且分辨率和图像属性始终相同。
  2. 自己解析流以向管道提供带有时间戳的 au 对齐缓冲区。
4

1 回答 1

1

经过一番摸索，我终于找到了造成这种情况的根本原因。而且有点晦涩难懂。。

无人机中的无线视频发射器能够根据无线电链路的可用带宽动态改变视频比特率。或者换一种说法：当无人机距离太远或有强烈干扰时，视频质量会下降。

发生这种情况时，视频帧（仅包含在单个 NAL 中的一个切片中）开始显着变小。由于我正在读取没有特定对齐的 h264 流的 512 字节块并将它们作为 GstBuffers 转发到 GStreamer，如果一帧所需的数据大小低于 512 字节，则缓冲区可能包含多个帧. 在这种情况下，h264parse 将其视为具有相同时间戳的 N 个不同缓冲区。然后，默认行为似乎是忽略上游 PTS 和 DTS，并尝试通过从 SPS 读取 VUI 来根据帧的持续时间计算时间戳，这在我的流中不存在。因此，离开 h264parse 的 source pad 的缓冲区将没有 PTS 也没有 DTS，从而使 mp4mux 抱怨。

正如我之前提到的，我的流非常简单，所以我编写了一个简单的解析器来检测每个 NAL 的开头。通过这种方式，我可以“解压”来自 USB 硬件的流，并确保推入我的管道的每个缓冲区都只包含一个 NAL（因此，最多为一帧），并带有独立的时间戳。

并且为了冗余，我添加了一个连接到我的 tee 元素的接收器垫的探针，以确保我在每个缓冲区中都有正确的时间戳。否则，他们将被迫像这样运行元素。

if (!GST_BUFFER_PTS_IS_VALID(buffer) || !GST_BUFFER_DTS_IS_VALID(buffer))
{

    GstElement* elm = gst_pad_get_parent_element(pad);
    qCDebug(VideoReceiverLog) << "Invalid timestamp out of source. Replacing with element running time.";
    GstClockTime ts = gst_element_get_current_running_time(elm);
    GST_BUFFER_PTS(buffer) = ts;
    GST_BUFFER_DTS(buffer) = ts;
}

完成此操作后，我无法再通过测试转储重现该问题。

于 2021-08-23T18:54:55.310 回答