[参考译文] SK-AM62A-LP：日期、当前时间（以毫秒为单位）、摄像头名称的 GStreamer 流式视频覆盖

您好 Steve、

对延迟深表歉意。

您在管道中的哪个位置尝试添加这些元素以嵌入日期和时间？ 它的位置也可能会导致延迟、因为这些是软件插件、并且基于软件和硬件的插件之间的切换可能会增加一些延迟、因此会出现帧丢弃。  

请与我们分享渠道。  

此致、

Suren

您好、Suren、

“对不起,我不知道该怎么办。“ 另外、我应该提到的是、这是使用 SDK-10.1 的下面的流水线：

gst-launch-1.0 v4l2src io-mode=dmabuf-import device=/dev/video3 ! video/x-bayer, width=2600, height=1952, format=grbg10, framerate=45/1 ! tiovxisp sink_0::device=/dev/v4l-subdev2 sensor-name=SENSOR_ONSEMI_AR0521 dcc-isp-file=/opt/imaging/ar0521/linear/dcc_viss_GRBG_10b_2600x1952.bin sink_0::dcc-2a-file=/opt/imaging/ar0521/linear/dcc_2a_GRBG_10b_2600x1952.bin format-msb=9 sink_0::pool-size=8 src_0::pool-size=8 ! queue ! textoverlay halignment=right valignment=bottom shaded-background=false shaded-background=true draw-outline=false draw-shadow=false font-desc="Mono, 10" text="CAM2-UpperLeft" ! queue ! clockoverlay halignment=left valignment=bottom shaded-background=false shaded-background=true draw-outline=false draw-shadow=false time-format="%D %H:%M:%S" font-desc="Mono, 10" ! queue ! v4l2h264enc extra-controls=controls,h264_i_frame_period=45,prepend_sps_and_pps_to_idr=1,video_gop_size=45 ! mpegtsmux ! udpsink host=xxx.xxx.xxx.xxx port=550xx

我可以看到使用 TI 跟踪器 python 脚本（上面的命令中添加了调试环境变量）、当 FPS 降至~35 时、tiovxisp0 元素中的延迟增加约 10（即~77）。 没有纹波覆盖层和时钟覆盖层元素的延迟要低得多 (~20),但似乎这是 Tracers 报告延迟的地方,即使它实际上是由这些其他流水线插件/元素引起的。

谢谢您、

Steve

您好 Steve、

您能否分享示踪剂屏幕截图以了解正在运行的管道的 FPS 和延迟方面。

此外、您是否可以将摄像头配置为较低的分辨率并查看行为是否发生变化？

此致、

Suren

以下是   上面提供的 gstreamer 流水线的跟踪器、接近 45 FPS：

如果没有覆盖层、我可以看到恒定的 45FPS、tiovxisp 的延迟数字要低得多：

以下是 gstreamer 管道中的跟踪器、两个覆盖层的字体大小均从 10 更改为 16：

我目前不能轻易地更改到其他分辨率、因为这将涉及一些驱动程序工作、不管怎样、我都需要它才能用于此分辨率。

此致、

Steve

您好 Steve、

对延迟深表歉意。

我已将您的查询转递给我们的专家、他不在办公室。 请留出一两天时间来回复在流水线中添加叠加组件时 tiovxisp 延迟为何不同的原因。

此致、

Suren

您好 Steve、

我尝试了叠加时间、然后使用 8M@30fps 摄像头流式传输到显示器、但没有看到任何 fps 帧率下降：

GST_DEBUG_FILE=/run/trace.log GST_DEBUG_NO_COLOR=1 GST_DEBUG="GST_TRACER:7" GST_TRACERS="latency(flags=element)" \
gst-launch-1.0 -v v4l2src device=/dev/video-imx728-cam0 io-mode=dmabuf-import ! \
video/x-bayer, width=3856, height=2176, format=rggb12, framerate=30/1 ! \
tiovxisp sink_0::pool-size=2 sink_0::device=/dev/v4l-imx728-subdev0 sensor-name=SENSOR_SONY_IMX728_UB971_D3 \
dcc-isp-file=/opt/imaging/imx728/wdr/dcc_viss_wdr.bin sink_0::dcc-2a-file=/opt/imaging/imx728/wdr/dcc_2a_wdr.bin format-msb=11 wdr-enabled=true ! \
queue ! video/x-raw, format=NV12 ! tiovxmultiscaler target=0 ! video/x-raw, format=NV12, width=1920, height=1080 ! queue ! \
mosaic_0. tiovxmosaic name=mosaic_0 target=1 src::pool-size=2 sink_0::startx="<200>" sink_0::starty="<0>" sink_0::widths="<1520>" sink_0::heights="<850>" ! \
video/x-raw,format=NV12, width=1920, height=1080 ! queue ! \
textoverlay halignment=right valignment=bottom shaded-background=false \
shaded-background=true draw-outline=false draw-shadow=false font-desc="Mono, 10" \
text="CAM2-UpperLeft" ! queue ! \
clockoverlay halignment=left valignment=bottom shaded-background=false shaded-background=true \
draw-outline=false draw-shadow=false time-format="%D %H:%M:%S" font-desc="Mono, 10" ! queue ! \
kmssink driver-name=tidss sync=false skip-vsync=true

您是否可以尝试流式传输到显示器、而不是通过以太网进行编码和发送？ 这可以帮助我们确定瓶颈所在。

谢谢、

建中

您好 Steve、

多尺度可能是瓶颈。 您能再尝试两件事吗？

1.在 tiovxmultiscaler 之前添加一个“队列“元素

2. 保留 tiovxmultiscaler 并使用 fakesink

谢谢你。

建中

尊敬的建中：

根据您的请求：

1. 在 tiovxmultiscaler

2.  保留 tiovxmultiscaler 并使用 fakesink

我发现 tiovxisp 没有更高的延迟、我 使用以 1920x1200 运行的不同图像传感器尝试这种情况。 这种大小的分辨率是否是影响延迟的重要因素？

谢谢您、

Steve

您好 Steve、

这个大小的分辨率是否是造成延迟的重要因素？

是的、可以。  

具有 fakesink（使用和不使用 tiovxmultiscaler）的测试结果表明、多标量可能是瓶颈。 您能否尝试我在以下主题中提供的补丁？

AM62A7-Q1：3840x2160：无法以 30fps 的速率运行使用 VISS 和 LDC 的 VPAC — 处理器论坛-处理器 — TI E2E 支持论坛

请在上述主题的以下帖子中找到该补丁：

此致、

建中

以下是应用补丁并使用 tiovxmultiscaler 后的一些跟踪器结果：

1.使用 fakesink

2.使用 kmssink 代替 fakesink

此致、

Steve

您好 Steve、

使用 fakesink 可显示 45fps、这意味着多标量贴片会有所帮助。

您能否共享使用 kmssink 的管道？

谢谢、

建中

下面是我用于 kmssink 的流水线：

gst_debug_file=/run/trace.log gst_debug_no_color=1 gst_debug=“gst_Tracer:7" gst_tracers"“ gst_tracers" delay“ delay (flags=element)“ gst-launch-1.0 v4l2src io-mode=dmabuf-import device=/dev/video3！ 视频/x-Bayer、宽度=2600、高度=1952、格式=grbg10、帧速率=45/1！ tiovxisp sink_0：：device=/dev/v4l-subdev2 sensor-name=SENSOR_ONSEMI_AR0521 dcc-isp-file=/opt/imaging/ar0521/linear/dcc_viss_GRBG_10b_2600x1952.bin sink_0：：dcc-2a-file=/opt/imaging/ar0521/linear/dcc_2a_GRBG_10b_2600x1952.bin format-msb=9 sink_0：：：pool-size=8 src_0：：pool-size=8！ 排队！ tiovxmultiscaler target=0！ video/x-raw、格式=NV12、宽度=1600、高度=900！ 排队！ Textoverlay halignd=right valignd=bottom shading-background=false shading-background=true drap-outline=false drap-shadow=false font-desc=“mono, 10“ text=“CAM2-UpperLeft"！“！ 排队！ clockoverlay halignment=左值装饰=底部阴影背景=false 阴影背景=true drain-outline=false drain-shading=false time-format=“%D %H:%M:%S“ font-desc=“单色、10“！ 排队！ kmssink driver-name=tidss sync=false skip-vsync=true

谢谢、

Steve

我没有收到一封电子邮件,当我发布了上述回复,我已经遇到了一些问题,登录和发布今天... 发布此文章是为了查看这次是否通过系统、并向线程发送更新的通知/电子邮件。

您好 Steve、

您的显示屏是否支持 45fps？

如果删除文本覆盖层和时钟覆盖层、该怎么办？ 这会使帧率达到 45 吗？

谢谢、

建中

尊敬的建中：

显示原始分辨率以 60 Hz 运行。 它似乎能尽可能支持 45 Hz 的视频流。 移除纹理覆盖层和时钟覆盖层会产生以下示踪剂：

下面是我使用的流水线：

GST_DEBUG_FILE=/run/trace.log GST_DEBUG_NO_COLOR=1 GST_DEBUG="GST_TRACER:7" GST_TRACERS="latency(flags=element)" gst-launch-1.0 v4l2src io-mode=dmabuf-import device=/dev/video3 ! video/x-bayer, width=2600, height=1952, format=grbg10, framerate=45/1 ! tiovxisp sink_0::device=/dev/v4l-subdev2 sensor-name=SENSOR_ONSEMI_AR0521 dcc-isp-file=/opt/imaging/ar0521/linear/dcc_viss_GRBG_10b_2600x1952.bin sink_0::dcc-2a-file=/opt/imaging/ar0521/linear/dcc_2a_GRBG_10b_2600x1952.bin format-msb=9 sink_0::pool-size=8 src_0::pool-size=8 ! queue ! tiovxmultiscaler target=0 ! video/x-raw, format=NV12, width=1600, height=900 ! queue ! kmssink driver-name=tidss sync=false skip-vsync=true  

谢谢、

Steve

嗨、建中、

您是否能够提供有关为什么在跟踪器报告中的流水线 tiovxisop 部分而不是叠加部分中报告延迟的任何见解？

我曾查看过 RidgeRun 插件、但它似乎不支持时间（以毫秒为单位）。 我一直在 尝试使用自定义 gstreamer 应用程序 、该应用程序使用 textoverlay 插件以当前日期和时间更新文本参数（在从身份插件回调期间）、但 textoverlay 与其他两个插件的覆盖方式非常相似、并且仍然可以在跟踪器的 tiovxisp 中观察到一些帧下降和较高的延迟。

谢谢、

Steve

您好 Steve、

您是否能够提供任何见解、说明为什么在跟踪器报告中的流水线 tiovxisop 部分而不是覆盖层中报告延迟？

我也有这个问题。 我不完全了解 GStreamer 如何计算每个元素的延迟。

此致、

建中

您好、建中、

我一直在努力、以期在这里使用 gstreamer 叠加插件为延迟和丢弃帧提供良好的解决方案。 我发现、减小覆盖框的大小（即用于缩短长度的字符数，用于高度的字体大小）可以大大减少延迟。 我可以得到大约 55 个开始的延迟（尽管我看到它在运行时增加到 68 个、然后开始每次下降~1/100）、使用“Mono、8px“字体在文本字符串中总共使用 24 个字符。 我认为这基本上是此配置不丢弃帧的限制。 如果我使用的文本字符串具有相同的字体和大小、但总共只有 19 个字符、则延迟约为 16-18。  不幸的是, 当使用完整的日期和时间格式（即 YYYY-MM-DD HH:MM:SS.MM 是 22 个字符）时,这只留下几个字符来表示相机名称,因此,似乎有必要在那里找到一个平衡,以减少日期/时间戳,以便以我想要的方式使用 textoverlay 插件。

我使用 gstreamer 应用更新每一帧的 textoverlay 插件文本字段、以获得我所需的毫秒级分辨率功能  、但我怀疑在使用带有 GST 启动管道的时钟覆盖时、上述字符大小和长度影响/限制适用于某些配置、尤其是另外使用其“文本“元素属性时。

根据一些额外的研究,在我看来, 延迟 可能与 Pango 的内存管理、图像分辨率大小和文本有关,以高效地渲染 CPU 缓存中的所有配件,以便尽快处理。 如果可能、请更正或阐明该理论。

我从另一家公司的产品中找到了这个解决方案、该产品使用定制叠加插件来与片上 GPU 交互、因此它可能并不高度适用于 AM62Ax（但或许对于其他 TI 处理器来说，这很有意义）。

https://github.com/Freescale/gstreamer-imx/pull/147

是否有类似 TI 希望提供的解决方案？

此致、
Steve T

您好 Steve、

感谢您分享其他信息。 TI 不太可能提供您提到的客户插件等产品。

此致、

建中