This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM5728:勘误表 i839问题

Guru**** 2553420 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/569957/am5728-errata-i839-questions

器件型号:AM5728

您好!

我想我们可能会遇到勘误表 i839、因此我对此有几个问题。 这是我参考的勘误表、以供参考。

i839某些 RGB 和 YUV 格式具有非标准排序
中等严重程度
说明数据格式定义是非标准的,因此会产生颜色组件
如果在软件中做出错误假设、则交换。
要为每个活动数据通道配置数据打包/解压缩逻辑、VPDMA (在
VPE 和 VIP)依赖于通道数据传输中的"数据类型"值
描述符。 因为组件顺序方向不匹配、所以不能使用
VPDMA 指定了常用图像标识符的颜色组件及其预期的颜色
可在显示屏和写入存储器的视频/图像数据中交换
一些 RGB 和 YUV 数据类型。
指南软件驱动程序应将自定义格式重新映射到所需的行业标准格式
和/或根据需要将数据视为字/字节交换。 另请参阅器件 TRM 以了解完整信息
数据格式说明。
修订版本影响 SR 1.1、2.0

描述很模糊、我有一些具体问题。

1.它说"颜色组件可以交换"。  这种说法对我来说意味着在交换时有一些条件、在交换时有其他条件。 什么情况会导致交换?

一些  RGB 和 YUV 数据类型。 导致问题的具体数据类型是什么? 都是这样吗? 只有一个子集、如果是、是哪一个子集?

指南建议我们在驱动程序软件中进行一些重映射。 这是在 TI 处理器 SDK 中完成的吗?

谢谢

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    您使用的是什么软件? Linux 还是 RTOS?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Linux
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    谢谢。 软件团队已收到通知。 他们将在这里作出回应。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    使用的是哪个版本的 Linux 内核、用例是什么? 从内核版本3.14起、PLSDK 将在 VIP 驱动程序中处理此字节反转(i839芯片勘误表)。  

    VIP 驱动程序仅接受 UYVY 作为传感器的输入数据格式、以处理 i839勘误表。  由于这个勘误表、当 VIP 接收到字节时、在硬件中交换字节。 因此、传感器发送的 UYVY 数据格式将成为 VIP 接收的 YYYYV 格式。 VIP 内部的所有处理(如缩放、颜色空间转换、数据格式转换等)都在 YUV 模式下进行。 因此、传感器应以 UYVY 发送数据。  VIP 在其他 YUV 422订单中收到的数据将导致颜色处理错误。

    如果在 VIP 内部不需要进行内部处理、并且只需将数据写入存储器、则可以通过设置 VPDAM 来否定 VIP 接收器侧的硬件完成的字节交换、以便在将数据写入存储器之前再次交换这些字节。 查看此 e2e 帖子-  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我们使用的是 PSDK 03.00.04、因此是内核4.4.4.12。

    您所描述的内容听起来与我们看到的问题相同、但我想确保。 我们有一个定制的 Omnivision 传感器、可输出到 AM572x 8位 YUV422。 字节作为 Y-U-Y-V-Y-U-Y-V-等 形式进入 VIP 我们使用 gstreamer 捕获文件的帧、然后在 PC YUV 查看器中查看该文件。 颜色已关闭。 如果我们调整 YUV 播放器设置以交换端模式、颜色看起来正常。 但是、我怀疑通过这样做、我们也会交换相邻的 Y 值。

    我们将使用以下 g-streamer 命令进行捕获、

    gst-launch-1.0 v4l2src device=/dev/video1 num-buffers=5 io-mode=4! 'video/x-raw、format=(string) YUY2、width=(int) 1072、height=(int) 992、framerate=5/1'! VPE! 'video/x-raw、format=(string) YUY2、width=(int) 1072、height=(int) 992、framerate=5/1'! 文件链接位置=singal_cam_1072x992_1.yUV

    听起来、我们需要 Omnivision 传感器板输出 UYVY、因为我们仅使用8条数据线、因此每次输出将为8位。 如果我们使这种情况发生、gstreamer 命令会是怎样的? 我假设我们必须用其他东西替代 YUY2格式说明符?

    谢谢

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    实际上、在重新阅读您的描述后、我们所要做的似乎就是将数据作为 UYVY 馈入、解析器会将字节交换回 YYV。 话虽如此、gstreamer 命令应与之前相同、对吧?

    还有一点、解析器中是否有 FIFO? 我问、如果我们一次以一个字节发送数据、除非解析器一次捕获多个字节、否则如何交换字节? 交换的 U 和 V 字节是否仅意味着 Y 值不受影响?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 user="Brad Caldwell ">实际上、在重新阅读您的描述后、我们所要做的似乎只是将数据作为 UYVY 馈入、解析器会将字节交换回 YYV。 [/报价]

    正确。

    [引用 user="Brad Caldwell "]话虽如此, gstreamer 命令应与以前相同,正确吗?[/quot]

    正确

    [引用 user="Brad Caldwell "]、除非解析器一次捕获多个字节、否则如何交换字节? 交换的 U 和 V 字节是否意味着 Y 值不受影响?

    解析器内部具有 FIFO、无论物理数据接口大小如何、如果数据类型定义为 YUV、解析器将其视为16位数据并交换这些16位中的字节。 因此、如果传感器正在发送 U0 Y0 V1 Y1、则解析器会将其转换为{Y0 U0}、{Y1、V1}等。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    谢谢 Manisha、您的帮助非常好!
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Manisha、
    抱歉、我将此主题标记为已回答、核心问题已回答、但我还有一个后续问题。

    如果出于某种原因、我们无法更改传感器向 VIP 发送数据的顺序、我们如何使用 VIP 设置进行更正? 由于我们的图像尺寸太大、我们将不会使用 VIP 的 CSC 或缩放功能。

    如果有一种方法可以使用 VIP 设置进行更正,则 gtreamer 命令会是什么样子? 我是一个新手、不太熟悉 gstreamer。

    谢谢
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    目前、VIP 仅期望传感器发送 UYVY 格式数据。 如果传感器发送任何其他内容、协商将失败。 因此、更改不仅限于 gstreamer 命令、还包括 VIP 驱动程序。

    如果传感器未发送 VIP 所期望的数据类型、则需要在 vi.c 文件中的 vIP_format[]数组中创建另一个条目、该文件位于内核驱动程序/媒体/平台/ti-VPE 内。

    静态结构 vp_fmt vp_format[vp_MAX_ACTIVE_FMT]={

    fourcc= V4L2_PI_FMT_NV12、
    .code= media_BUS_FMT_UYVY8_2X8、
    .colorspace= V4L2_colorspace_SMPTE170M、
    .coplanar= 1、
    .vpdma_fmt={_vpdma_yuV_fmts[VPDma_data_FMT_Y420]、
    &vpdma_yuV_fmts[VPDMA_DATA_FMT_C420]、
    }、
    }、

    将.code 条目更改为传感器发送的类型、并将 vpdma_fmt 更改为应用程序预期的数据类型。 检查 TRM 中的表9.38。
    第4位(DATA_TYPE)=交换了 U/V (在 U/V 之间交换)
    第5位(DATA_TYPE)= UV/Y 交换(在 Luma 和 Chroma 分量之间交换)-仅适用于交错数据类型

    对于 gstreamer、请使用 gstreamer 命令查找 video/x-raw src 支持的格式
    #gst-inpect v4l2src

    您可以访问此站点、了解不同的格式、并选择满足您的需求的格式-
    http://www.fourcc.org/yuv.php
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    有点奇怪、我对它有另一个扭曲。 目前、我们将以 YUV422格式送入视频帧、很快将更改为 UYVY。 但是、我们将使用的另一种模式是传感器板将通过 MJPG 数据发送、我们只想在其中捕获原始数据、不需要 CSC 也不需要调节。 勘误表对此有何影响? 我被告知无法预交换传入的数据、因为传感器板上的 MJPG 生成逻辑是固定的、无法更改。

    在这种情况下、我们是否需要更改驱动程序? 我们似乎会告诉 VPDMA 不适当地进行解析器的交换。 因此、如果我们必须对 MJPG 进行驱动程序更改、那么同样的更改可能适用于 YUV422、因此我们应该继续以 YUV422的形式发送非 MJPG 视频帧。 这有道理吗?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 user="Brad Caldwell "]。 因此、如果我们必须对 MJPG 进行驱动程序更改、那么同样的更改可能适用于 YUV422、因此我们应该继续以 YUV422的形式发送非 MJPG 视频帧。 这是否合理?

    正确。 只需使用 vpdam fmt 值0x27即可撤消交换。