同样叫 Linux 设备，芯片架构、工具链、音频驱动和可用内存可能完全不同。评估 RTC 接入可行性时，一份准确的设备资料比一句“需要低延迟视频”更有帮助。建议把以下内容汇成一页，并为未知项注明确认时间。
系统与构建条件
提供芯片型号、处理器架构、系统版本、运行库、编译工具链和应用语言。若存在多个硬件版本，应标出首期支持的型号。不要用系列名称代替具体版本，也不要把开发板的配置直接当作量产设备条件。
再确认应用运行权限、安装与升级方式、是否允许常驻进程，以及生产固件能否导出必要日志。SDK 能编译通过只是第一步，还需要确认运行环境和长期维护路径。
音视频输入与输出
列出摄像头和麦克风访问方式、原始或编码后的数据格式、可用编码器、扬声器输出接口及时间戳来源。说明媒体是否还会被本地录像、识别算法或其他应用同时使用。
若只有厂商封装后的接口，需要提前索取接口说明和可运行示例。无法访问实时媒体时，应先解决设备侧开放能力，再确定 RTC 接入工作量。浏览器媒体接口规范可以帮助理解采集能力，但不能替代原生系统适配说明。
网络与会话关系
写清 Wi-Fi、有线或蜂窝网络，目标国家和地区，是否进入企业网络，以及对端使用浏览器、应用还是设备。用一句具体场景描述参与关系，例如“一台机器人与一个手机用户双向通话，管理员只在故障时进入查看”。
同时说明设备如何被绑定、谁能发起呼叫、凭证如何获取和刷新、挂断后是否释放媒体。身份和业务权限应在整体系统中设计，不能仅凭知道房间号就认定可以加入。
资源预算与验收材料
提供典型业务负载下可用的处理器、内存、电量与散热空间。没有准确数据时，先安排测量，不要直接套用空闲设备的结果。准备样机、稳定复现步骤、预期上线时间与首期验收任务，方便安排验证顺序。
最终资料应把“已确认”“待样机测试”“待供应商答复”分开。这样报价中的接入范围、前置条件和排期才有共同依据。
以上为通用准备清单，SDK 兼容性与性能需按具体版本核验。需要评估 RTC 接入与报价，可通过本站提交资料摘要，避免在公开表单中发送设备密钥或访问凭证。
参考：W3C Media Capture and Streams，用于理解媒体采集能力与设置，不是硬件兼容清单。