請求接口返回錯誤，提示“請求被禁止”

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。

• 播放端網絡不佳

  播放器若持續一段時間都未能拉到流或者檢測到網絡斷開會往上層拋出錯誤，屬于正?，F象。

  說明

  對于播放端拉流錯誤（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)）。

同一個云存錄像播放時畫面清晰度會出現變化

這屬于正?，F象。云存錄像是當前云存錄像上傳和直播復用同一路通道，云存記錄期間直播的清晰度如果發生變化，對應的云存錄像清晰度也會跟著變化。

連續云存錄像不連續

產生這一現象的主要原因有以下幾點。

• 設備出現重啟：請結合設備端日志排查

• 設備因網絡原因離線：請結合設備端日志排查，可通過生活物聯網控制臺定位的離線時間

• 設備推流異常中斷：請結合設備端日志排查

• 設備使用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類型音量大小。