Link Visual的常见问题

请求接口返回错误，提示“请求被禁止”

Link Visual服务未开通，请参见快速体验Link Visual。

请求接口返回错误，提示“Stream push failed”

产品中缺少对应功能依赖的物模型，请按照各功能依赖的物模型描述检查是否缺少物模型，并参见新增标准功能添加物模型。

例如：语音对讲功能中未勾选物模型StartVoiceIntercom服务时，当发起对讲请求时会收到该错误。

为什么首帧时间大

如果设备正常响应强制I帧指令（以办公室的WiFi为例），设备响应强制I帧耗时300ms以内的话，一般首帧的延迟应在1.5秒以内。

首帧耗时= 请求播放地址耗时（300ms）+连接播放地址耗时（150ms）+等待设备I帧耗时（300ms）+播放器内部缓冲延迟（200ms）+解码渲染耗时（10ms）

导致首帧延迟时间大的原因主要有以下两种情况。

• 设备未正常响应强制I帧指令时，会增加一个GOP长度的延迟，此时您需要使设备正常响应强制I帧指令。

• 设备端连接推流地址耗时大，此时请通过控制台右上角的工单联系我们。

为什么直播播放卡顿

产生播放卡顿、画面跳帧的原因主要有以下几种情况。

• 设备SDK缓冲区设置过小

  Link Visual设备端SDK提供码流比特率设置接口，SDK内部会通过传入的比特率换算并设置缓冲区大小，若码流比特率设置过小，会导致设备端SDK缓冲区频繁触发丢包，从而影响画面质量。此时建议您重新设置合适的SDK缓冲区。

  说明

  Link Visual目前不支持帧大小超过512KB的码流传输。

• 设备网络不佳

  若设备所处网络上行带宽不足以支持设定的码流传输，会引起设备端SDK缓冲区频繁丢包，从而影响画面质量。建议您调整设备位置或者检查设备网络状态。

• 播放端网络不佳

  播放端所处下行网络带宽至少需要大于当前码流，播放器提供获取码流的接口可以用来展示当前实际码流信息。请检查播放端网络带宽是否符合要求，并建议您展示当前码流（建议码流展示样式为：24fps 80KB/s），便于以后定位问题。

• 码流问题

  Link Visual不支持B帧，H264建议使用BaseLine/Main Profile。

  最大码流与清晰度对照表如下。

  编码格式	分辨率	最大码流
  H264	1080P	<2Mbps
  	720P	<1Mbps
  	D1	<0.5Mbps
  H265	1080P	<1.5Mbps
  	720P	<0.75Mbps
  	D1	<0.5Mbps

• 解码耗时大

  当编码复杂或帧超大引起解码耗时大，进而引起播放器主动丢帧，导致画面卡顿，此时建议您降低设备编码复杂度和码流大小。

• 设备时间戳异常

  前后两帧之间PTS/DTS差值应与实际编码器生成帧时时间戳差值保持一致。

  • 若Link Visual的时间戳两帧之间差值比实际大，会引起播放端解码器延迟解码，可能会触发播放器缓冲区溢出丢帧，引起画面慢放和画面卡顿。

  • 若Link Visual的时间戳两帧之间差值比实际小，会引起播放端解码器提前解码，引起画面快放。

  说明

  推荐您使用设备端SDK提供的码流自检功能做时间戳检查。

直播播放断开

产生播放过程中画面静止一段时间后报错的原因主要如下。

• 设备推流异常

  设备因网络断开或者程序bug引起推流突然中断，若非网络引起，需要结合设备端日志进行分析，排除bug。

• 播放端网络不佳

  播放器若持续一段时间都未能拉到流或者检测到网络断开会往上层抛出错误，属于正常现象。

  说明

  对于播放端拉流错误（1100），建议App在实现时主动做1-2次的重试逻辑，若仍失败则呈现给用户重试。

清晰度切换时出现花屏

IPC设备通过多码流切换实现清晰度切换，当设备响应清晰度切换指令时，推流从码流1切换到码流2，需要立即停止码流1的推流，并需确保等到码流2下个GOP的I帧重新开始推流。请根据该流程检查业务逻辑是否正确。

播放器边播边录失败

播放器收到I帧开始才会真正启动录制，若从调用开始录制接口到调用结束录制接口的时间过短，且期间未收到I帧，则本次录制会失败。手机上应保证足够的剩余空间用于保存录制的Mp4文件。

建议您做以下的限制或提醒。

• App上对录制时间做一定的限定，对用户过短的录制行为做出提示，明显小于一个GOP时长不允许调用结束接口。

• App上对应对最大录制时长做限制，每次开启录制之前应判断当前剩余空间能否满足存储最大录制时长的文件。

查询卡录像列表时，提示“服务超时”

App请求设备录像点播列表通过物模型服务来实现，请求提示以下错误。

code:20056
message:gateway.hsf.invoke.timeout
localizedMsg:后端服务超时

引起问题的主要原因是，设备端未能在指定的同步服务超时时间（3秒）内，处理该次卡录像查询操作。

建议您通过建立文件索引等方式优化查询速度，保证24小时范围的数据查询请求一定能在3秒内执行完毕。

卡录像seek响应慢

优化建议：对于大文件通过增加文件内索引的方式实现快速定位到指定时间附近I帧的能力，需要保证推送的第一帧为I帧。

卡录像播放画面速率异常

与直播实时生成视频帧发流不同，卡录像点播的发流速率和时间戳是人为控制的，如果控制的不合理会影响到播放效果。

常见的几种现象如下。

按文件方式播放卡录像，获取文件duration始终是0

一般是设备端SDK未在开始推流前获取到文件长度，请结合设备端日志排查，确认是否有正确的duration长度回传给SDK。

边播边录时播放正常，但是录制保存的mp4文件在播放时会跳帧或者花屏

一般与设备时间戳异常有关，如果播放端收到前后两帧时间戳一样的视频帧，mp4录制时会丢帧，导致花屏或跳帧，需要设备端修复。

多个用户同时观看同一个设备卡录像时有些用户出现播放失败

设备端SDK默认只支持一路并发观看，当有多路观看时，按照抢占式处理，始终保证最后一个用户能正常观看。

优化建议：设备端SDK支持并发路数调整，默认只允许一路，请结合当前设备能力和业务场景来调整并发参数，不建议超过4路。

如何在码流扩展自定义信息

设备厂商可以通过SEI帧在视频码流中叠加自定义的信息：如算法标注结构数据、鱼眼矫正等信息。

SEI帧符合H264/H265中的标准定义即可。通过Link Visual提供的播放器可以收到自定义的SEI二进制数据, 为整个SEI的NAL unit（不包括NAL start code(0x00 0x00 0x01|0x00 0x00 0x00 0x01)）。

同一个云存录像播放时画面清晰度会出现变化

这属于正常现象。云存录像是当前云存录像上传和直播复用同一路通道，云存记录期间直播的清晰度如果发生变化，对应的云存录像清晰度也会跟着变化。

连续云存录像不连续

产生这一现象的主要原因有以下几点。

• 设备出现重启：请结合设备端日志排查

• 设备因网络原因离线：请结合设备端日志排查，可通过生活物联网控制台定位的离线时间

• 设备推流异常中断：请结合设备端日志排查

• 设备使用H265码流一次推流过程中发生过清晰度切换：当前H265设备推流中如果切换清晰度，云存录像会重新生成切片，查询按两个文件处理

云存录像查询接口返回的beginTime与视频文件中OSD水印时间不一致

beginTime是以流媒体服务器收到首个视频I帧时参考服务器的时间生成，OSD水印时间参考的设备时间，相对来说服务器时钟误差可控，接近UTC时间，而嵌入式设备因为内置时钟误差以及对时策略的问题容易有较大误差。除开时钟不准的影响，另外需要确认下设备端的视频帧缓冲区是否过大从而牺牲实时性，导致服务端收到的数据时间比时机偏晚。误差计算公式 = 设备时钟误差+ 设备视频帧缓冲延迟 + 网络耗时（<500ms） + 服务端处理耗时（<100ms）， 理论上整体误差应控制在2秒以内。

云存录像播放器可以边播边录吗？

可以，并且还支持云端录像下载，可下载后播放。

事件图片存储周期是多久

当前Link Visual服务开通后，每个设备免费赠送3天图片云存储空间（后续可能会调整），具体套餐信息请以正式合同为准。

根据推送消息查询不到对应的事件录像

产生这一现象的原因主要有以下两点，可根据具体情况作出处理。

• 事件上报最小时间间隔限制为10秒，不区分具体的事件类型，若设备端上报间隔小于该值，则会触发事件限流从而不会生成录像。设备端事件上报应增加最小间隔的过滤，并确认事件上报最小时间间隔是否大于10秒。

• 因网络原因可能会出现设备上报事件成功但未能响应推流。此时请检查网络环境，或稍后重试。

App与设备不同时区时，怎么处理？

App可能跟设备使用时处于不同时区，为保证时间准确有效，Link Visual SDK和服务端接口统一使用UTC时间。

下面以设备录像点播功能为例子说明如何实现“按设备时间查询和播放设备录像”的业务流程。

• 设备时区信息设定

  1. App完成与设备的配网绑定后，通过时区物模型属性，默认下发时区配置信息给设备。

  2. 用户可在App设置页面自行切换设备时区。

  3. 设备OSD时间（屏显水印时间）使用设备时区时间显示，PTS/DTS时间戳使用UTC时间，随帧保存到录像文件中。

• App播放请求流程如下

  1. App日历和时间轴按照设备的时区显示当前的日历和时间。

  2. 用户选择要观看的时间范围时（设备时间0点到24点），获取时间范围的UTC时间戳作为beginTime和endTime传给设备端（查询录像列表）。

  3. 设备根据beginTime和endTime过滤符合条件的录像文件块返回给App（设备响应查询）。

  4. App使用设备返回的UTC时间转化为设备所处时区时间进行显示，始终与OSD时间一致（App展示和播放）。

设备端无法听到对讲声音

• 请检查App端录音权限是否打开

• 请检查设备物模型扬声器属性是否已开启

手机和设备近场双讲时啸叫声明显

近场双讲的啸叫较难解决，应尽量避免近场双讲的情形出现。如遇上该情形可以通过降低一方扬声器音量或者捂住麦克风来改善。

双讲时听到回声是怎么回事

需要先区分回声来自哪端，再做相应措施。

• 如果在设备端说话，能在设备端听到自己刚说内容的回声

  此时是因为手机回声消除效果不好，双讲方案中使用的是硬件AEC，iOS手机回声效果比较好，Android手机绝大部分能生效回声消除，若发现回声消除效果不佳的手机请向我们反馈。

• 如果在手机端说话，能在手机端听到自己刚说内容的回声

  此时是设备的回声消除效果不好，可能的原因有以下几种。

  • 设备未开启回声消除算法。

  • 腔体结构设计影响（麦克风和扬声器之间隔离不佳）。

  • 扬声器失真。

  • 麦克风增益调节过大，引起录音截幅。

  如果设备回声消除问题无法得到很好的解决，即无法满足双讲的要求，建议您切换为单讲方案。

语音对讲收到"code":9543 "message":"voice intercom existed"的报错提示

以下两种情况会出现以上错误提示。

• 过频繁的在App端快速开启和关闭对讲

  例如快速开关对讲，设备还在处理上次对讲结束请求，来不及响应下次请求，属于正常情况。

  此时建议您在上次对讲结束后，不要立即开启下次对讲，对App端用户过频的操作可以增加防护和相应的提示语。

• 设备异常

  例如设备一直无法响应下次对讲请求，该问题属于bug，需要结合设备日志来进一步分析。

Android播放器使用GLSurfaceView作为播放器UI时，播放有声音但无画面，使用截图能正常获取到图片

请根据以下流程来排查该问题。

1. 检查是否设置了GLSurfaceView以及其容器的背景色，如果设置了则需要去掉。

2. 检查GLSurfaceView在Activity的onResume和onPause回调方法中，是否缺失调用GLSurfaceView的onResume和onPause方法。

Android播放器VodPlayer播放结束后为什么还会收到onError回调，提示pull stream error

设备录像点播功能在播放完毕后不会主动关闭连接，需要在收到OnCompletionListener.onComplete()回调后主动调用stop()来关闭，否则超过8秒会提示该错误。

Android手机音量调小后，打开对讲时手机音量突然变大

Android系统下音量调节是按照流类型来分别配置的，默认按音量键操作的是Music类型音量，对讲开启后使用的Phone Call类型音量，请确认手机的Phone Call类型音量是否开到了最大，可以通过AudioManager来调整Phone Call类型音量大小。