[参考译文] TDA4VH-Q1：wave5 ko 队列错误

您能否详细说明一下随机值的含义？  

它是在 Linux 还是其他一些高级操作系统中？ 您能否共享您正在编码的视频以便我重新创建？ 您是否使用 gstreamer 或其他某个应用？

​​使用 RAND 生成的随机值。

程序使用我编写的 v4l2、而不是 gstreamer。 它可以正常用于普通图像。

0x05意味着什么？

产生该误差的原因可能是什么？

Enguo、

我不确定该误差究竟意味着什么。 我也不确定我是否完全理解你要做的事。

testpic 是一个将随机值插入到的奇异图片数组吗? 您说这是 nv12图像、但该方法如何分离该格式的亮度和色度分量？ 它看起来像一维阵列而不是二维阵列,我认为这将是正确的一个随机图像的正确方法。 使用 nv12格式范围内的有效值填充宽度 x 高度 x 1.5的每个条目。

如果可以将其与您所说的正常图像一起使用、那么我认为问题一定在于生成此随机图像的方式、而不是编码器排队的方式。

此致！

布兰登

testpic 的长度是宽 x 高 x 1.5。 定义是这样

逻辑可能与这类似、

这会生成一个包含随机值的图像、

G_width = 1024；g_height=640

然后将该图像复制到 v4l2_buf 以进行编码

随机数时、我可以执行相同的操作。 相反、使用普通映像复制到 testpic、编码将是正常的、没有错误。

因此、我认为由于这种随机值图像、编码可能会有问题。 但我不知道该错误消息意味着什么、

我想在图像发生很大变化时测试比特率的变化、因此我使用随机值​​进行测试。

然后、我遇到此问题

尊敬的 EnGuo：

我们正在努力获取您的问题的答案。 感谢您的耐心。

谢谢。  
萨拉贝什

谢谢、希望能尽快得到回复

尊敬的 EnGuo：

我们的专家目前是 OOO、因此请预计答案会延迟。

谢谢！
萨拉贝什

好的，没问题

尊敬的 EnGuo：

对此深表歉意-上周就没了。

正如我在上面的响应中提到的、您可以尝试使用二维阵列而不是一维阵列来执行此操作吗？ 我不确定该错误代码映射回什么。 我没有所有映射供我使用。

请尝试使用随机值方法使 testpic 成为二维数组、确保值范围也介于16-235之间。 我相信这是 nv12中的一组可能值。

谢谢。

布兰登

我认为二维数组和一维数组的存储器空间分配是相同的。 但我可以尝试一下。


为什么存在范围限制16-235？ 我不太明白这一点。 您能解释一下吗？

我从 NV12规范中获得了这些数字。 每个分量都给定8位、因此您期望的范围是0-255。 不过,这实际上不是我所读到的情况。  

我检查了一些信息、发现16-235的范围源自 BT.601-5和 BT.709-5。 这是 RGB 和 YUV 转换规范。

我还尝试了16-235范围内的图像,并发现仍然有问题。

我以1024*640的分辨率保存了图像。 您能在那里进行测试吗？

但是、我无法将图像文件上传到 e2e。 是否有其他方法可以上传图像文件？

我将其上传到下面的链接

tidrive.ext.ti.com/.../be05e7f1-198f-48ce-9b1f-20e46e62352f

访问代码：redj282、

感谢您的分享。 您只测试一个简单的编码吗？ 我应该意识到正在启用的任何其他参数或功能？

我刚刚使用以下命令进行了尝试、并出现了相同的错误。

gst-launch-1.0文件 rc location=./testpic ！ rawvideoparse width=1024 height=640 format=nv12帧速率=30/1! v4l2h265enc！ filesink location=./video sync=true

因此、您也可以使用 gstreamer

我的 v4l2程序包含一些商业代码。 可能无法在您的设备上工作

我无法重现我的编码器产生队列错误的问题。 但是、我看到设备挂起的问题。 同样、我不确定使用随机生成的图片时编码器在单帧情况下的工作原理。 我发现在尝试单独对不使用随机值的单个帧进行编码时会出现问题。 我将与 Cnm 讨论、并询问这些误差值是怎样转化的、从而为您提供帮助。

你是否收到队列错误？ 这是照片

此打印是否可能是由于 DEV_dbg 未打印出，但实际上发生了这种情况？

我使用 sdk8.6、并且 EVM 板在运行命令时会打印该内容。 当然、我做了一些小的修改、将 DEV_dbg 更改为 DEV_err。

我已将日志更改为执行 pr_info。 如果它到达那里、我就知道。 但是、我尝试对这个单个随机帧进行编码并不会获得任何日志。 我正在使用的管线为：

gst-launch-1.0文件 rc 位置=testpic blocksize=983040! video/x-raw，width=1024，height=640，framerate=30/1, interlace-mode=progressive, colorimetry=bt601，format=NV12！ v4l2h265enc！ fakesink

您与我分享的管线无法正常工作。 由于驱动程序非常相似、我一直使用9.0 SDK、 其中最显著的 区别是用户空间。 尤其是 gstreamer 版本。 请给我时间与 Cnm(wave5制造商)一起工作,我将通过进一步的步骤返回给您。

好的、非常感谢

您好、CNM 有任何反馈吗？

很抱歉没有更新此 TT。 我一直在与他们讨论这已经向我显示的单帧编码错误。

即使不使用您的随机值图像、而是使用我拥有的 h264文件中的单帧、它也可以成功解码为 YUV RAW 帧。 但是、该奇异帧的编码过程将会挂起。 这个错误仍在继续、我们正在努力寻找解决方案。  

您是否意味着对单个帧进行编码会导致挂起？ 无论此帧中的图片是什么样子的？

另外、您能帮我问一下0x05错误代码是什么意思吗？ 在我知道这意味着什么之后,我可以尝试自己解决它。

Enguo、

我刚刚听到 CNM 的回复。 此错误是命令队列已满导致的。 Wave5有一个内部命令队列-此命令队列的默认驱动程序深度为2。 它可以增加、但会增加内存消耗。 如果发送帧的速度快于编码器能够处理帧的速度、则设备将抛出此错误。  

在这种情况下、需要在时隙打开后再次等待并发送命令。

谢谢、我会尝试修改它、

但我只输入一帧。 我不明白命令队列为什么被填满。

我知道为什么排队失败：0x05错误报告

因为当我使用 testpic 进行编码时、无法触发中断。 当我稍后输入其他帧时、队列将是完整的(testpic 是随机值图片)

我在中断中添加了打印

从上面的日志可以看出、在我输入 testpic 后、不能生成中断。

为了方便测试、我修改了测试文件。 将在第六个帧中发生错误。 您也可以在此处尝试。

gst-launch-1.0 filesrc location=./testyuv  ! rawvideoparse width=1024 height=640  format=nv12 framerate=30/1 ! v4l2h265enc ! filesink location=./video  sync=true

文件名为testyuv，

tidrive.ext.ti.com/.../be05e7f1-198f-48ce-9b1f-20e46e62352f

访问代码：redj282、

我发现在使用 sdk8.6的 wave5驱动程序时没有问题,但在使用 sdk9.0的 wave5驱动程序时会有问题。

我似乎发现了问题。 我把

更改为 

它运行成功

我发现该帧的大小为774169=756KB。 (如果您使用 gstreamer 运行它、您会发现这个帧的大小比我的小。 因为我设置了比特率、所以它会大于 gstreamer 命令执行生成的大小。)

但是、我应该将 sizeimage 设置为多大的尺寸？

不确定此 SDK 版本中的驱动程序是否有差异。 在8.6至9.0之间、驱动程序实际上非常相似。 最可能的区别是 gstreamer 版本、因为 gstreamer 的核心架构发生了多大的变化。  

我最近将这个补丁发送到我们的内核： https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-linux-6.1.y-cicd&id=12598d7a3ca52f5166b67cc714329029b4502543。  

您能否将它应用到您的诊断树、看看它是否解决了此处的问题？

谢谢。

布兰登

我知道此补丁允许在外部设置 sizeimage。 但我想知道 sizeimage 应该设置为什么值。 是否有任何相关标准？

我不知道标准是什么。 由于您正在编写自己的应用程序、因此我建议您遍历 gstreamer 层、以查看它请求的大小。 我们的驱动程序要么使用默认大小计算、要么使用 gstreamer 请求我们分配的任何内容。

我发现 gstreamer 在 sdk8.6中设置的 imagesize 是2M，这可能会导致大图像出现问题。 您能帮助我问一下最安全的尺寸图像应该设置为什么吗？

或者是否有任何图像质量修改建议、以确保图像尺寸不大于当前值？

我还尝试了使用 gstreamer、在 sdk9.0下会发生相同的问题

您好！

我对您的问题有点困惑。 您能否澄清一下"确保图像尺寸不大于当前值"的含义？ 你说电流值是什么意思？ 对 gstreamer 值或驱动器值的引用。 它是在输出(原始流)侧请求2M 还是在捕获(编码流)侧请求？

您目前遇到的问题是什么？ 没有为位流缓冲区分配足够的存储器？  

我共享的映像大小补丁直接来自 CNM。 他们要么使用 gstreamer 请求、要么根据他们认为的需要计算值。 但是、gstreamer 有时可以请求更多的数据、因为 Cnm 算法没有考虑其他参数、因此我们采用了最大值。 我将询问 Cnm 团队、他们是否有其他考虑了其他参数的图像尺寸计算方法。

此致！

布兰登

我已经测试并发现 gstreamer 在捕获(编码流)侧设置了固定的大小2M。 当原始图形为小分辨率图像时、这不是问题、但当原始图形为大分辨率图像时、可能会出现问题

问题是,我使用的是1024*640图像(后来发现编码生成的帧大小是778635),它比编码驱动程序中的 sizeimage=height*weight/8*3大得多,甚至比高和重量高。 导致编码驱动程序卡住(在后续输入其他图像后不会中断)

我尝试将编码流的大小改为与输入流相同的大小，即高度*weight*3/2，工作正常。 但是、这会导致内存占用过多、无法满足我们编码的业务需求。 因此、我想提出以下问题、

应设置什么大小的映像以确保编码流不会超过 buf 大小？

2、编码流大小与图像质量的关系。 能否通过修改图像质量来解决此问题？ 但我不知道具体的设置值。

3.是否有办法限制如此大的图像生成？

4.如果出现此问题，是否有办法稍后恢复？ 中断将不再被触发。

对不起,我不小心在上面的文本中写入了重量而不是宽度。 应为宽度

您好！

感谢您的澄清。 在回答问题之前、我想和 Chips-n-Media (Cnm)团队一起探讨这个问题。 原因是、即使在上游提交中、他们也做出了使用与先前版本的原始驱动程序中相同的数学表达式来设置捕获(编码数据)大小图像的设计决定。 但是、解码器输出(要解码的传入编码数据)取数学表达式或任何 gstreamer 请求的最大值。 我想向他们报告并了解他们的意见、以便我们能够制定更高效的算法、使您的内存不会受到太大影响。

我亦会就上游提交的资料发表意见。 请给我几天时间再回复这一问题。 我现在将和他们一起买票,明天将与他们见面,我可以得到更多的细节。  

谢谢。

布兰登

非常感谢。 期待您的反馈

还有一个问题、CBR 和 VBR 的大小限制是否会不同？

我发现,在 VBR 的情况下,编码流输出的大小几乎不会超过高度*重量,但当 CBR 和比特率设置为高值时,很容易超过高度*重量。 是否有办法限制 CBR 的最大大小？

将此添加到会议的讨论点。 我不太熟悉分辨率、速率控制模式和编码比特流大小之间的关系。

您能与我分享一个有关此行为的示例吗？

简单地说、比特率是每秒编码数据的大小。 在 VBR 模式下设置比特率无效。 VBR 将优先考虑确保图像质量。 此时、每秒编码数据输出的大小为随机值。 在 CBR 模式下、数据大小将遵循设置的比特率。 此时、每秒编码数据大小很可能为固定值。

但这并不代表任何一帧的大小。 因为假设一秒有30个帧、那么比特率是这30个帧的大小之和

Enguo、

我收到一条信息、指出这个问题已被提升到高优先级。 我们仍在研究使用 CMM 的解决方案、以便针对压缩缓冲区大小进行适当的协商。 目前更新不多。 今天晚上我将与他们举行另一次会议、因此我将要求提供有关此问题的最新信息。

此致！

布兰登

您好、最近有新消息吗？

尊敬的 EnGuo：

我和 Chips-N-Media (CNM)的工程师一直在讨论如何确定图像大小的正确算法。 问题是 v4l2 API 使其变得有点困难。 当在输出和捕获队列中调用 S_FMT ioclts 时，驱动程序还不知道为特定流上下文设置的编码参数。 我现在要问的是、是否可以调用此 wave5_update_pix_fmt (设置 sizeimage) 在所有 s_ctrl 调用完成后-或者每次 s_ctrl 调用完成后、因为我不确定 v4l2是否有方法向驱动程序传达哪个控制是最后一个控制。

CNM 提供的另一种解决方案是仅使用 编解码器规格中使用的 MaxCpbSize 公式。 但是 、这会在大多数情况下分配过多的存储器、并且不适合您的用例。  

我想告诉您、我最近移植了最新版本的上游驱动程序、以便与我们的内核版本(6.1)匹配。 如本线程前面所述、我看到了使用此流水线的一般单帧编码情况中存在的问题：  

gst-launch-1.0 filesrc location=testpic blocksize=983040 ! video/x-raw,width=1024,height=640,framerate=30/1,interlace-mode=progressive,colorimetry=bt601,format=NV12 ! v4l2h265enc ! filesink location=video.265

使用更新的驱动器、可以正常处理单帧编码。 但是、再说一次、该版本的驱动程序仍然使用以前的方法、即根据我之前在此线程中共享的补丁来分配压缩的缓冲区大小。 我只是想和你们分享这个,因为这个版本的驱动程序已经被上游接受。 据信它更加稳健和可靠。 它很快将成为我们公共内核的一部分。

我会促请 CNM 把这列为高度优先的事项、以便我们能够更快地找到解决方案。 但考虑到 v4l2 API 的实现方式、在缓冲区分配时并非所有信息都可用、这一点很复杂。 我已经通过其他几个上游驱动器了解他们是如何做到的,我还没有发现它在任何地方都这样做。 从我所看到的内容来看、很多驱动程序都在使用默认 sizeimage (随附其应用程序分配的任何内容)。

在您的用例中、您是否使用设定的分辨率和比特率进行编码？ 如果是这种情况、如果默认情况是此时分配了过多的存储器、那么我建议您在驱动程序中对大小映像进行硬编码、以适合您的用例。 我知道这个主题刚刚讨论过1024x640、但我不确定是否有其他分辨率需要支持。

由于您没有将 gstreamer 用作主机应用程序、因此无法仅使用您自己的算法来设置那里的大小映像、因为您将知道要设置的所有参数？ 我正在寻找此类算法的示例、但尚未找到任何将所有这些参数关联到适当压缩缓冲区大小的表达式。 如果我能够找到此主题、或者 CNM 是否为我提供适用于其硬件的建议、我将更新此主题。

此致！

布兰登