[参考译文] SK-AM69：编码和解码的性能测试问题

您好！  

我认为延迟的原因是文件链接插件。 当写入文件(尤其是4k 流)时、将产生不可避免的大量 CPU mem 副本。 因此、 编码器必须方便地将 CPU 负责复制的许多兆字节数据写入存储设备。 您可以尝试改用 fakesink 来运行流水线、然后应该会看到延迟测量结果得到改善：  

• gst_debug_file=gst_trace.log gst_debug_no_color=1 gst_debug="gst_Tracer：7" gst_tracer="latency (flags=Element)：v4l2" time gst-launch-1.0 filesrc location=/bbb4k60_HEVC.YUV！ rawvideoparse 宽度=3840高度=2160格式=nv12帧速率=60/1比色法=bt709！ TEE 名称=t \
  T.！ 队列！ v4l2h265enc！ fakesink \
  T.！ 队列！ v4l2h265enc！ 链接
  

我们的性能指标与 v4l2h265硬件加速器元件相隔离、因此可能会发生其他驱动程序和缓冲器延迟、具体取决于用例。  

此致！
Sarabesh S.

大家好、Sarabesh Srinivasan：

我尝试使用 fakesink 插件、在4K60时仅实现1个流的性能、但无法在4K60时同时实现2个流的实时性能。 我找到了一些关于您提到的 AM69编解码器的信息、它们支持高达8192x4320的分辨率、但它不是实时的。

您好！  

我认为、在 AM69上运行两个4k60流时、可能没有指定正确的 VPU 实例。 我目前正在研究这个问题。  

我找到了一些有关您提到的 AM69编解码器的信息、该编解码器支持高达8192x4320的分辨率、但它不是实时的。

在本主题中、我参考8192x4320最大编码/解码分辨率和4k60 RT 保证基于每个 VPU IP。 AM69有两个 VPU IP 实例、因此功能是2倍。 因此、AM69应支持两个4k60 RT 保证流。

谢谢！
Sarabesh S.

您好！  

     您的测试结果似乎表明、仅使用一个线程进行编码时、10秒的视频文件需要9.59秒才能处理。

gst_debug_file=gst_trace.log gst_debug_no_color=1 gst_debug="gst_Tracer：7" gst_tracer="latency (flags=Element)：v4l2" time gst-launch-1.0 filesrc location=/bbb4k60_HEVC.YUV！  rawvideoparse 宽度=3840高度=2160格式=nv12帧速率=60/1比色法=bt709！  TEE 名称=t \
T.！ 队列！ v4l2h265enc！ fakesink \
T.！ 队列！ v4l2video3h265enc ! 链接

当同时对两个线程进行编码时、15秒的总处理时间超过了视频文件的持续时间、因此无法实现对两个线程进行4k60的实时编码。

您好！  

您的测试结果是正常的；单个程序  输出帧速率超过60fps。

不过、我的问题是、在同时对两个程序进行编码时、帧速率无法达到60fps、而只能达到37fps。 换句话说、两个程序无法实时编码才能实现60fps。

e2e.ti.com/.../gst_5F00_trace.txte2e.ti.com/.../gst_5F00_trace1.txte2e.ti.com/.../gst_5F00_trace2.log

你好、Sarabesh 和？？ ？

我不确定测试方法是否存在误解。 器件上有2个硬件 VENCDEC、应能够支持并行2通道编码、如何确保/确认测试为每个流并行使用了2个 VENCDEC、而不是仅使用一个 VENCDEC 对2个流进行串行编码？

您好！

您能给我介绍一下这两个测试用例的运行流水线吗？ v4l2h265enc0元素在 VPU0上运行编码器实例、v4l2video3h265enc0元素在 VPU1上运行第二个编码器实例。 因此、在单个流水线(如我之前的响应中所示)中、您将发送一个要由 VPU0编码的流、以及另一个要由 VPU1编码的流。

管道中的"tee"元素将要发送到多个目标的数据流拆分、"queue"确保流在单独的线程上运行以确保并行处理、而不同的 v4l2编码器元素是不同的 VPU 目标。

请向我提供您运行的两个流水线、以便我可以看到为您提供37 fps 结果的原因。 另外、如果您可以向我提供您使用的确切流、我可以在自己的环境中进行测试。

BR、
Sarabesh S.

我在以前的回复中发现了命令/流水线、它与您的相同。 客户在不同的 ssh 控制台中运行两个实例、以确保两个实例并行运行。  

不知道如何并行运行两个实例。 如果逐个执行、则处于串行模式、而不是并行模式。

BTW、客户使用了相同的 YUV 文件： bbb4k60_HEVC.YUV

好了、如何更改流水线以并行对2个不同的视频源文件进行编码。  

您好、Sarabesh：

  我使用以下命令测试 两个不同的文件、/tmp/bbb4k60_hevc.yuv /tmp/bbb4k60_hevc.yuv1.yuv  

• gst_debug_file=gst_trace.log gst_debug_no_color=1 gst_debug="gst_Tracer：7" gst_tracer="latency (flags=Element)：v4l2" time  gst-launch-1.0 filesrc location=/tmp/bbb4k60_hevc.yuv！ rawvideoparse 宽度=3840高度=2160格式=nv12帧速率=60/1比色法=bt709！ 队列！ v4l2h265enc！ fakesink \
  filesrc location=/tmp/bbb4k60_hevc.yuv1.yuv！ rawvideoparse 宽度=3840高度=2160格式=nv12帧速率=60/1比色法=bt709！ 队列！ v4l2video3h265enc ! 链接

结果仍然表明、它无法实现两个不同文件的实时60fps 流。  UESD 时间13.71s OUT-fps 40+

您好！

您是否可以将您正在使用的完整600帧输入文件发送给我、以便我可以在我的环境中进行测试？ 您应该能够压缩并将其附加到该线程。 我没有该大小的4K 文件。 此外、您所使用的 SDK 版本是什么？

此致！
Sarabesh S.

文件太大、大小为7GB。 我可以提供一个 MP4文件供您使用以下命令。生成

gst-launch-1.0 filesrc location=./bbb4k60_hevc.mp4 ! qtdemux name=demuxer demuxer.! h265parse ! queue ! \
v4l2h265dec ! rawvideoparse width=3840 height=2160 format=nv12 framerate=60/1 ! filesink location=/tmp/bbb4k60_hevc.nv12

e2e.ti.com/.../bbb4k60_5F00_hevc.zip

您好！  

我能够在 fps 输出低于60的情况下重现类似结果。 从我的测试来看、这似乎只是在管道中使用两个 filesrc 位置时出现的问题。 您能否确认使用 TEE 元素的以下流水线将满足时序要求并生成高于60的输出 fps？

• gst_debug_file=gst_trace.log gst_debug_no_color=1 gst_debug="gst_Tracer：7" gst_tracer="latency (flags=Element)：v4l2" time gst-launch-1.0 filesrc location=/bbb4k60_HEVC.YUV！ rawvideoparse 宽度=3840高度=2160格式=nv12帧速率=60/1比色法=bt709！ TEE 名称=t \
  T.！ 队列！ v4l2h265enc！ fakesink \
  T.！ 队列！ v4l2video3h265enc ! 链接

我将解释为什么在运行两个 src 文件时会出现这种情况。 我相信输入文件大小可能有一些限制、但会进一步调查并很快更新。

谢谢！
Sarabesh S.

您好！  

     Sarabesh Srinivasan 说：     

     在该流水线中 、您仍将运行2个4k60的编码。  TEE 元素在从 CPU 读取数据一次后复制流。 因此器件仍然存在  接收两个4k60输入。 即每个 VPU 1个4k60输入。  这是  不会  对两个 VPU 的1x 4k60流进行编码。 那么结果会是这样  不会  接近120fps。

     我使用以下命令获得了结果、它只有63 fps、 因此我认为性能没有达到120 fps。

• gst_debug_file=gst_trace.log gst_debug_no_color=1 gst_debug="gst_Tracer：7" gst_tracer="latency (flags=Element)：v4l2" time gst-launch-1.0  filesrc location=/bbb4k60_HEVC.YUV！  rawvideoparse 宽度=3840高度=2160格式=nv12帧速率=60/1比色法=bt709 ！ v4l2h265enc！ 链接

     Sarabesh Srinivasan 说：    

     对其进行研究后、这种行为是有意义的、因为 CPU 无法从磁盘中以足够快的速度读取两个较大的4k60文件、以满足 VPU 时间要求

     我还怀疑该问题可能与 CPU 读取磁盘数据的速度不足有关。 因此、我将 YUV 文件存储在 tmp 目录中、该目录是基于内存的文件系统。

v4l2h265dec！ 功率因数

     是否有其他任何测试方法可以验证实时双通道4K60编码和解码的性能？

您好！

本周我不在办公室、因此请期待能有延迟的回复。

谢谢！
Sarabesh S.

您好！

我使用以下命令获得了结果、它只有63 fps、 因此我认为性能没有达到120 fps。

• gst_debug_file=gst_trace.log gst_debug_no_color=1 gst_debug="gst_Tracer：7" gst_tracer="latency (flags=Element)：v4l2" time gst-launch-1.0  filesrc location=/bbb4k60_HEVC.YUV！  rawvideoparse 宽度=3840高度=2160格式=nv12帧速率=60/1比色法=bt709 ！ v4l2h265enc！ 链接

您不会看到120fps、这高于器件支持的像素速率。 最大处理能力为500MP/s (百万像素/秒)。 不支持120 FPS 的4K 分辨率流。 TDA4VH 上的 Wave5的时钟频率稍高、因此我们看到的速度实际上超过500MP/s 这就是为什么您看到的解码帧速率为95 fps 的原因。  

Im 不确定我们在哪里介绍了有关获取120 FPS 的内容。 你是  不会  在 Wave5的2个实例之间拆分视频-无法实现、因为我们不支持这一点。 当 Sarabesh 分享了下面看到的管道时,他展示了如何将1个视频复制到2个源,这样我们就不会两次读取两个编码器的磁盘了。 TEE 元件会用于创建多个数据焊盘。 在两个编码器之间重复信息。 该流水线本质上与2个不同的文件 SRC 相同、但您通过使用 TEE 元素来节省 CPU 带宽。 因为这个原因,每个 wave5实例应该给你大约60FPS -因为这是 wave5支持的。

 gst-launch-1.0  filesrc location=/bbb4k60_HEVC.yuv !  rawvideoparse 宽度=3840高度=2160格式=nv12帧速率=60/1比色法=bt709！  TEE 名称=t \
T.！ 队列！ v4l2h265enc！ fakesink \
T.！ 队列！ v4l2video3h265enc ! 链接

v4l2h265dec！ 功率因数

这里显示95 fps、因为没有同步。 正如我在上面提到的、Wave5的时钟频率更高、因此您将看到超过4K 60FPS。 如果要查看60FPS、可以将流水线更改为此值：

Brandon、您好！

客户需要从2个不同的源进行2通道4K60fps 编码、我不确定上面的说明是否提供了清晰的命令/流水线来实现？ 然后、BU 端验证了使用情况吗？

Brandon、您好！

我补充了 Tony 的内容、这里我想测试两种不同的视频流 实时 编码或解码。

您好！  

对于4K60的两个通道之类的设备、它需要来自摄像机源、以便您可以在摄像机和编码器之间设置 dmabufs。 编码器可以处理4K60而不会出现问题、我们已在上面进行了证明。 在这种情况下、CPU 是限制因素。 必须从磁盘读取如此多的数据太多了。 CPU 每个数据流必须每秒读取大约750兆字节。 有两个流时、容量将达到数千兆字节。 两个唯一的文件源是不可行的-它需要读取太多的原始数据。  

谢谢！

Brandon

您好！

   必须从磁盘读取如此多的数据太多了。  因此、我将 YUV 文件存储在 tmp 目录中、该目录是基于内存的文件系统。  这种方法是否可行？

您好！  

我将对此进行探讨、并检查可行性。 我们明天会向您提供这些信息。

谢谢！

Brandon

Brandon、您好！

    这种方法是否可行？

您好！  

由于 Linux 开销导致无法将/tmp 读取作为满足文件读取时序要求的有效方法、因此从/tmp 读取是不可行的。 验证两个不同4k60流的正确方法是通过系统级用例、其中运行摄像头捕捉来编码流水线。 目前正在内部讨论对这一点的支持。  

谢谢！
Sarabesh S.

Brandon、您好！

每个流每秒必须读取大约750兆字节。 有两个流时、容量将达到数千兆字节。 两个唯一的文件源是不可行的-它需要读取太多的原始数据。

https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j784s4/09_02_00_05/exports/docs/devices/J7_Family/linux/Release_Specific_Performance_Guide．html？highlight =基准测试

SDK 性能 数据中没有表头、有些数据要高得多、而某些数据在同一行中很小。  

我们是否可以从  LMBench 存储器基准标志数据中获得结论？  

尊敬的 Tony：  

将深入了解这一点并让您知道。

谢谢！
Sarabesh S.

你(们)好

我在两个单独的控制台上测试了这两条命令：

gst_debug_file=/run/trace3.log gst_debug_no_color=1 gst_debug=2、"gst_Tracer：7" gst_tracer="latency (flags=Element)" gst-launch-1.0 multifilesrc stop-index=0 location="gst" index=0 loop=0 caps="video/x-raw /opt/test_3840_2160.yuv、width=3840、height=2160！ v4l2video3h264enc！  链接

gst_debug_file=/run/trace.log gst_debug_no_color=1 gst_debug=2、"gst_Tracer：7" gst_tracer="latency (flags=Element)" gst-launch-1.0 multifilesrc stop-index=0 location="gst" index=0 loop=0 caps="video/x-raw /opt/test_3840_2160.yuv、width=3840、height=2160！ v4l2h264enc！  链接

帧速率为56和58。 剂量满足您的要求？

此致、

Adam

您好！

我还尝试了从不同的图像读取:

gst_debug_file=/run/trace.log gst_debug_no_color=1 gst_debug=2、"gst_Tracer：7" gst_tracer="latency (flags=Element)" gst-launch-1.0 multifilesrc stop-index=0 location="/opt// TEST_2_3840_2160 .YUV" index=0 loop=1 caps="video/x-raw , width=3840, height=2160, format=NV12"! v4l2h264enc！  链接

gst_debug_file=/run/trace3.log gst_debug_no_color=1 gst_debug=2、"gst_Tracer：7" gst_tracer="latency (flags=Element)" gst-launch-1.0 multifilesrc stop-index=0 location="/opt// TEST_3840_2160 .YUV" index=0 loop=1 caps="video/x-raw , width=3840, height=2160, format=NV12"! v4l2video3h264enc！  链接

帧速率分别为58和57。

此致、

Adam

我使用5个图像进行循环编码、性能只能达到40fps 以上。

gst_debug_file=/run/trace.log gst_debug_no_color=1 gst_debug=2、"gst_Tracer：7" gst_tracer="latency (flags=Element)" gst-launch-1.0 multifilesrc location="/opt//  TEST_%04d .yuV" start-index=0 stop-index=4 loop=1 caps="video/x-raw、width=3840、height=2160、format=NV12"！ v4l2h264enc！  链接

我使用了 perf 工具进行分析、

您好！

对此进行调查、并向您更新下周开始的情况。

谢谢！
Sarabesh S.

您好！  

查看流水线后、请注意、在运行循环编码5次时、您仍在读取多个4k60文件源。 这将导致无法满足 fps 要求、因为文件源正在从磁盘读取4次。

谢谢！
Sarabesh S.