前端通信【免費(fèi)下載鏈接】decimen-optical-transfer項(xiàng)目地址https://gitcode.com/gh_mirrors/de/decimen-optical-transfer點(diǎn)擊查看免費(fèi)下載導(dǎo)讀Decimen 是一個通過屏幕 QR 碼流實(shí)現(xiàn)設(shè)備間單向光學(xué)傳輸?shù)拈_源項(xiàng)目發(fā)送端把文件編碼為連續(xù) QR 幀接收端用攝像頭解碼。由于這條鏈路沒有回傳信道一旦某個環(huán)節(jié)失配故障往往表現(xiàn)為攝像頭在跑、畫面在動、卻一個字節(jié)都解不出來。本文以 docs/user/troubleshooting.md 為主體系統(tǒng)梳理三類高頻故障——無信號Nothing happening、版本不匹配Update 提示、攝像頭異?！⒀由斓铰賯鬏?shù)恼{(diào)優(yōu)手段。讀完你可以按文檔給出的順序逐條修復(fù)同時了解這些建議在源碼層面的實(shí)現(xiàn)依據(jù)做到知其然也知其所以然。一、Nothing happening?無信號提示是怎么工作的1.1 提示行為與觸發(fā)規(guī)則如果攝像頭運(yùn)行了一段時間卻一幀都解不出來接收頁預(yù)覽上方會彈出一條小型 toastNothing happening?沒有任何畫面解碼出來。toast 上有兩個按鈕Help打開詳細(xì)排查建議列表Dismiss暫時關(guān)閉提示但它之后還會回來——因?yàn)辄c(diǎn)一下按鈕并不會讓幀開始到達(dá)。只有當(dāng)真正解析出第一幀時提示才會永久消失。這套何時提示、何時重提的時序策略不是散落在頁面里的setTimeout而是封裝在 shared/no-signal.ts 的NoSignalHintTimer類中純計(jì)時策略、不含任何 DOM 邏輯。其規(guī)則非常清晰倒計(jì)時從攝像頭啟動那一刻開始使用較短的首次延遲用戶Dismiss 后按更長的延遲重新倒計(jì)時——建議已經(jīng)被看過一遍提示不必再頻繁打擾攝像頭重啟視為一次全新嘗試回到短延遲第一幀解析成功即永久終止無論提示當(dāng)時是否在屏幕上——這是唯一真正表明鏈路已經(jīng)打通的信號。在 receive/main.ts 中兩個延遲被定義為NO_SIGNAL_FIRST_MS 8_000首次 8 秒和NO_SIGNAL_DISMISSED_MS 15_000Dismiss 后 15 秒。這些規(guī)則都有對應(yīng)的單元測試逐一驗(yàn)證見 tests/no-signal.test.ts例如提示只在倒計(jì)時結(jié)束后的第一次 tick 觸發(fā)一次Dismiss 后恢復(fù)更長的延遲已解碼過一幀則任何后續(xù)重啟都不再提示等邊界情況都被覆蓋。1.2 修復(fù)順序問題幾乎總在發(fā)送端排障文檔反復(fù)強(qiáng)調(diào)一個反直覺的事實(shí)無信號的修復(fù)動作在發(fā)送端。按文檔給出的順序依次嘗試順序操作說明1打開發(fā)送端Transfer settings把bytes / frame 降到 1465默認(rèn) 2953 字節(jié)是為近距離手機(jī)對手機(jī)調(diào)優(yōu)的在臂長距離的普通顯示器上恰好是最容易失敗的配置2仍然無解把發(fā)送端tx fps 降到 24降低幀率給攝像頭更多曝光與對焦時間3讓接收畫面充滿整個取景框并把手機(jī)靠穩(wěn)/架住手持微顫導(dǎo)致的自動對焦來回搜索autofocus hunting是常見的元兇4把發(fā)送屏幕的亮度調(diào)到最高增加 QR 碼的對比度與信噪比注意順序不能跳先降密度bytes/frame再降速率tx fps。如果一上來就降 fps 而幀仍然過密問題依舊。1.3 源碼層面的證據(jù)建議值與下拉框的構(gòu)造性一致這些建議值不是文檔里隨手寫的數(shù)字而是與發(fā)送端 UI 共享的常量。見 shared/send-settings.tsexport const NO_SIGNAL_HINT_FRAME_BYTES 1465; export const NO_SIGNAL_HINT_TX_FPS 24;發(fā)送端的下拉選項(xiàng)TX_FPS_OPTIONS10 / 15 / 20 /24/ 30 / 55 /60與FRAME_BYTES_OPTIONS500 / 1000 /1465/ 1850 / 2331 /2953都以這兩個常量構(gòu)造而接收端無信號提示的文案也由同一批常量生成見 receive/main.ts。這意味著提示給出的建議值永遠(yuǎn)存在于發(fā)送端的下拉框里——不會出現(xiàn)建議設(shè)一個 UI 里根本不存在的數(shù)值這類脫節(jié)。文件頭注釋明確寫道無信號提示命中的兜底值來自這里因此建議不可能指向發(fā)送端不提供的設(shè)置。為什么默認(rèn)的 2953 字節(jié) / 60 fps 會在普通顯示器上失效shared/send-settings.ts 的注釋給出了關(guān)鍵約束一幀至少需要在屏幕上停留約 2 個刷新周期否則攝像頭捕獲會正好截到幀切換的瞬間在 60 Hz 屏幕上每幀恰好只獲得一個刷新周期早期實(shí)測捕獲率只有 0.20.4。所以默認(rèn)值是為 120 Hz 高刷發(fā)送端與近距離場景設(shè)計(jì)的最優(yōu)演示配置而非普適配置——這正是排障文檔把 1465 和 24 作為第一、第二修復(fù)手段的原因。選項(xiàng)中的 55 也刻意低于 60 Hz 天花板讓幀邊界在掃描過程中漂移而非騎在刷新時鐘上避免連續(xù)兩幀在同一位置撕裂。1.4 順帶提示幀大小與塊數(shù)上限的關(guān)系把 bytes/frame 調(diào)低要留意一個邊界幀頭用 u16 編號源塊上限 65535 塊MAX_SOURCE_BLOCKS 0xffff見 shared/frame-capacity.ts。因此文件大小上限并不總是 64 MB——在 500 字節(jié)/幀下真正的上限大約只有 30 MB。發(fā)送端會在開始傳輸前用fitsInOneStream()檢查若超限會明確報錯并給出把 bytes / frame 提高到某個值或以上的建議該建議值也一定在下拉框選項(xiàng)內(nèi)見 send/main.ts。也就是說調(diào)低幀密度既能修復(fù)無信號也可能觸發(fā)大文件的容量報錯兩者都是同一個機(jī)制在工作。二、Update the sending device / Update this app版本不匹配2.1 發(fā)生了什么當(dāng)接收端識別出這是 Decimen 流但我讀不了時會彈出上述兩條更新提示之一。其本質(zhì)是兩臺設(shè)備處于不同的線纜格式wire format上。Decimen 0.5.0 改變了幀格式與 0.4.x 不兼容——兩端必須都在 0.5.0 或更新版本上才能互通。2.2 提示的方向語義消息會指明落后的是哪一側(cè)按你看到的那條對號入座Update the sending device更新發(fā)送設(shè)備——落后的是屏幕那一端Update this app更新本應(yīng)用——落后的是你手里這臺手機(jī)。2.3 關(guān)鍵的單向啞火0.4.x 接收端對 0.5.0 發(fā)送端毫無反應(yīng)這兩條提示是 0.5.0新增的能力因此存在一個不對稱場景接收端停留在 0.4.x 或更早、發(fā)送端是 0.5.0 時接收端什么也顯示不出來——只有第一節(jié)的 Nothing happening? toast。原因是舊接收端根本不知道幀里還有個版本號字段。這正是 docs/technical/versioning.md 所講的版本化設(shè)計(jì)動機(jī)v1→v2 曾經(jīng)在格式變更上花了一次 magic 升級卻沒換來版本字段導(dǎo)致發(fā)送端太舊與光線不好看起來完全一樣從 v3隨 0.5.0 發(fā)布開始接收端必須能說出到底是以下哪一種情況判定含義接收端行為ok可解碼解碼foreign不是 Decimen 幀靜默攝像頭會看到視野內(nèi)每一個二維碼older-senderDecimen但格式更舊Update the sending device.newer-senderDecimen格式更新Update this app to receive it.unsupported-flagsDecimen帶本端無法實(shí)現(xiàn)的特性Update this app to receive it.malformed是我們的幀但自相矛盾靜默與壞讀取無法區(qū)分這套判定邏輯集中在 shared/protocol.ts 的classifyFrame()中屏幕文案則由frameVerdictMessage()統(tǒng)一生成shared/protocol.ts——它緊挨著格式定義存放正是為了判斷結(jié)果與提示文案永遠(yuǎn)不會漂移且任何客戶端網(wǎng)頁、未來的 iOS/Android對同一失敗都說同樣的話。雙 magic 字節(jié)0xD1 0xC3的作用是在說出任何版本信息之前先回答這到底是不是我們的幀——僅憑單個0xD1把關(guān)時約 1/256 的隨機(jī)二進(jìn)制 QR 載荷會誤入版本分支被錯誤地要求更新一臺從沒運(yùn)行過 Decimen 的設(shè)備兩個字節(jié)把關(guān)后誤報率從 0.402% 降到 0.006%。如果你確認(rèn)發(fā)送端已是最新、接收端卻依然失明先更新接收端。從 0.5.0 起兩端都能指名格式不匹配所以未來再發(fā)生格式變更時無論哪一端更舊接收屏幕上都會說清楚。另一種什么都不顯示的可能則是接收端在看根本不屬于 Decimen 的二維碼——這類情況故意保持靜默詳見第一節(jié)接收端會解碼視野里的每一個 QR 碼包括櫥窗和商品包裝上的。2.4 修復(fù)方法使用 decimen.app 托管站點(diǎn)在兩臺設(shè)備上重新加載頁面。如果某臺設(shè)備被安裝到了主屏幕PWA后仍提示不兼容徹底關(guān)閉應(yīng)用再重新打開以強(qiáng)制刷新 service worker 緩存。使用獨(dú)立單文件從舊版本保存下來的decimen-sender.html與decimen-receiver.html彼此可以永久互通但不能與更新版本的對方配合。需要從同一個發(fā)布版本重新下載兩者。詳細(xì)說明見 docs/user/install-and-offline.md——其中解釋了托管站點(diǎn)、兩個獨(dú)立文件、演示模式三種形態(tài)以及為什么獨(dú)立接收文件從file://打開時拿不到攝像頭見下文第三節(jié)。三、攝像頭問題選錯鏡頭、權(quán)限拒絕、非安全上下文3.1 選錯攝像頭前置/長焦有些手機(jī)會把錯誤的鏡頭當(dāng)作后置攝像頭交給瀏覽器導(dǎo)致畫面里要么是前置自拍要么是一支只有站到房間另一頭才清晰的長焦。修復(fù)方式Receive settings → camera在列表里選擇正確的鏡頭。注意兩點(diǎn)列表在攝像頭啟動后才顯示真實(shí)鏡頭名稱瀏覽器在授予權(quán)限前會隱藏鏡頭名切換立即生效傳輸中途也可以切換。3.2 權(quán)限被拒絕Permission denied瀏覽器彈出權(quán)限詢問時要點(diǎn)得仔細(xì)——如果不小心點(diǎn)了 Block需要到瀏覽器設(shè)置里為該站點(diǎn)允許攝像頭然后回到頁面點(diǎn)Start camera重新啟動無需刷新頁面。3.3 camera needs a secure context該報錯意味著頁面正通過明文 http提供服務(wù)。瀏覽器會在非安全來源上整體移除攝像頭 API。解決方式通過https提供服務(wù)——項(xiàng)目自帶的開發(fā)服務(wù)器就是 https自簽名證書或使用托管站點(diǎn) decimen.app。這正是 docs/user/quick-start.md 中npm run dev啟動的是 https 開發(fā)服務(wù)器的原因localhost是豁免的但你手機(jī)訪問的局域網(wǎng) IP 不是。3.4 獨(dú)立接收文件無法獲得攝像頭在 iOS 或 Android 上從file://直接打開decimen-receiver.html不會獲得攝像頭——本地文件拿到的是不透明來源opaque origin移動端瀏覽器不給本地文件提供相機(jī)權(quán)限。解決方式見 docs/user/install-and-offline.md把該文件放到任意 http(s) 服務(wù)器上供手機(jī)訪問或者改用托管站點(diǎn)的離線模式。發(fā)送端沒有這個問題decimen-sender.html在所有平臺都能從file://直接運(yùn)行。四、慢速傳輸調(diào)優(yōu)的兩個杠桿如果鏈路已經(jīng)建立幀能解出來但傳輸龜速問題就從能不能解轉(zhuǎn)為解多快。排障文檔指向 docs/user/sending.md 的調(diào)優(yōu)表——bytes/frame 和 tx fps 是唯二真正起作用的旋鈕設(shè)置默認(rèn)值說明tx fps60為 120 Hz 發(fā)送端調(diào)優(yōu)在 60 Hz 屏幕上如果接收端停滯降到 24–30bytes / frame2953QR v40密度天花板——近距離手機(jī)對手機(jī)很好對顯示器或遠(yuǎn)距離要回退到 1465v27error correctionLfountain 層已經(jīng)處理擦除丟幀L 在這些幀尺寸下是正確的取舍display size900 px受屏幕上限約束全屏模式忽略此值默認(rèn)值偏向最佳演示場景。若傳輸爬行按順序bytes/frame → 1465tx fps → 24——與第一節(jié)無信號的修復(fù)順序完全一致。需要理解的是幀內(nèi)糾錯QR 的 ECC與 fountain 層解決的是兩類不同問題前者應(yīng)對幀內(nèi)局部損壞corruption后者應(yīng)對整幀丟失erasure。在整幀解碼或丟棄 fountain 冗余的策略下L 級糾錯配合約 K·1.15 的冗余幀docs/technical/protocol.md才是這尺寸幀的最優(yōu)組合。五、快速定位速查表綜合以上四節(jié)把癥狀與修復(fù)手段收斂成一張速查表便于現(xiàn)場快速定位癥狀優(yōu)先懷疑修復(fù)攝像頭在跑一幀不解toast 彈出發(fā)送端配置過密/過快按序執(zhí)行bytes/frame → 1465 → tx fps → 24 → 穩(wěn)住手機(jī) → 拉滿亮度顯示Update the sending device接收端比發(fā)送端新更新發(fā)送端設(shè)備到 0.5.0顯示Update this app發(fā)送端比接收端新更新接收端到 0.5.0接收端毫無反應(yīng)且發(fā)送端已最新接收端是 0.4.x 或更舊 / 或在看非 Decimen 碼先更新接收端確認(rèn)視野中確實(shí)是 Decimen 流畫面是前置鏡頭或長焦模糊瀏覽器選錯鏡頭Receive settings → camera 切換可傳輸中途切換提示 permission denied誤點(diǎn) Block瀏覽器允許站點(diǎn)攝像頭點(diǎn) Start camera無需刷新提示需要安全上下文明文 http走 httpsdev server 已自帶自簽名證書或托管站點(diǎn)獨(dú)立接收文件拿不到攝像頭file://不透明來源放到 http(s) 服務(wù)器或使用托管站點(diǎn)離線模式詳見 docs/user/install-and-offline.md能解碼但很慢密度/速率失衡bytes/frame → 1465tx fps → 24按此順序結(jié)語先讀提示再動設(shè)置Decimen 的排障哲學(xué)可以濃縮為兩句靜默失敗比大聲失敗更糟糕所以 0.5.0 之后任何讀不了的 Decimen 流都會指名方向修復(fù)動作幾乎總在發(fā)送端所以 Nothing happening? 的 toast 指向的是另一臺設(shè)備上的兩個下拉框。從源碼看這兩條哲學(xué)都不是靠文檔約定而是被寫進(jìn)了常量共享shared/send-settings.ts、幀判定邏輯shared/protocol.ts與計(jì)時策略shared/no-signal.ts中。遇到問題時按本文速查表從前往后逐條嘗試多數(shù)情況下第 12 步就能讓畫面重新流動起來。贊分享前端通信【免費(fèi)下載鏈接】decimen-optical-transfer項(xiàng)目地址https://gitcode.com/gh_mirrors/de/decimen-optical-transfer點(diǎn)擊查看免費(fèi)下載相關(guān)推薦iTerm2 Python API 腳本排障實(shí)戰(zhàn)指南從 Script Console 到 Ladybug 的完整排查鏈路iTerm2 Python API 腳本排障實(shí)戰(zhàn)指南從 Script Console 到 Ladybug 的完整排查鏈路 iTerm2 提供了基于 Py桌面應(yīng)用AI 應(yīng)用Ray on KubernetesKubeRay排障指南從版本匹配到 Autoscaler 的實(shí)戰(zhàn)問題排查Ray on KubernetesKubeRay排障指南從版本匹配到 Autoscaler 的實(shí)戰(zhàn)問題排查 本文是基于 KubeRay 官方排障文檔 t人工智能分布式訓(xùn)練強(qiáng)化學(xué)習(xí)任務(wù)調(diào)度模型推理服務(wù)后端OneUptime RUM 故障排查實(shí)戰(zhàn)指南從 Token 校驗(yàn)到數(shù)據(jù)落盤的完整排障鏈路OneUptime RUM 故障排查實(shí)戰(zhàn)指南從 Token 校驗(yàn)到數(shù)據(jù)落盤的完整排障鏈路 導(dǎo)讀 本文是 OneUptime Real User Monitor可觀測性后端運(yùn)維前端云原生微服務(wù)AI Agent上一篇HCCL experimental/ 實(shí)驗(yàn)空間貢獻(xiàn)指南目錄規(guī)范、運(yùn)行期開關(guān)與維護(hù)策略全解析下一篇new-api 計(jì)費(fèi)表達(dá)式系統(tǒng)billingexpr全解析一行表達(dá)式定義完整計(jì)費(fèi)邏輯創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Decimen 傳輸排障指南：從“畫面靜止“到“版本不匹配“的完整排查鏈路
前端通信【免費(fèi)下載鏈接】decimen-optical-transfer項(xiàng)目地址https://gitcode.com/gh_mirrors/de/decimen-optical-transfer點(diǎn)擊查看免費(fèi)下載導(dǎo)讀Decimen 是一個通過屏幕 QR 碼流實(shí)現(xiàn)設(shè)備間單向光學(xué)傳輸?shù)拈_源項(xiàng)目發(fā)送端把文件編碼為連續(xù) QR 幀接收端用攝像頭解碼。由于這條鏈路沒有回傳信道一旦某個環(huán)節(jié)失配故障往往表現(xiàn)為攝像頭在跑、畫面在動、卻一個字節(jié)都解不出來。本文以 docs/user/troubleshooting.md 為主體系統(tǒng)梳理三類高頻故障——無信號Nothing happening、版本不匹配Update 提示、攝像頭異?！⒀由斓铰賯鬏?shù)恼{(diào)優(yōu)手段。讀完你可以按文檔給出的順序逐條修復(fù)同時了解這些建議在源碼層面的實(shí)現(xiàn)依據(jù)做到知其然也知其所以然。一、Nothing happening?無信號提示是怎么工作的1.1 提示行為與觸發(fā)規(guī)則如果攝像頭運(yùn)行了一段時間卻一幀都解不出來接收頁預(yù)覽上方會彈出一條小型 toastNothing happening?沒有任何畫面解碼出來。toast 上有兩個按鈕Help打開詳細(xì)排查建議列表Dismiss暫時關(guān)閉提示但它之后還會回來——因?yàn)辄c(diǎn)一下按鈕并不會讓幀開始到達(dá)。只有當(dāng)真正解析出第一幀時提示才會永久消失。這套何時提示、何時重提的時序策略不是散落在頁面里的setTimeout而是封裝在 shared/no-signal.ts 的NoSignalHintTimer類中純計(jì)時策略、不含任何 DOM 邏輯。其規(guī)則非常清晰倒計(jì)時從攝像頭啟動那一刻開始使用較短的首次延遲用戶Dismiss 后按更長的延遲重新倒計(jì)時——建議已經(jīng)被看過一遍提示不必再頻繁打擾攝像頭重啟視為一次全新嘗試回到短延遲第一幀解析成功即永久終止無論提示當(dāng)時是否在屏幕上——這是唯一真正表明鏈路已經(jīng)打通的信號。在 receive/main.ts 中兩個延遲被定義為NO_SIGNAL_FIRST_MS 8_000首次 8 秒和NO_SIGNAL_DISMISSED_MS 15_000Dismiss 后 15 秒。這些規(guī)則都有對應(yīng)的單元測試逐一驗(yàn)證見 tests/no-signal.test.ts例如提示只在倒計(jì)時結(jié)束后的第一次 tick 觸發(fā)一次Dismiss 后恢復(fù)更長的延遲已解碼過一幀則任何后續(xù)重啟都不再提示等邊界情況都被覆蓋。1.2 修復(fù)順序問題幾乎總在發(fā)送端排障文檔反復(fù)強(qiáng)調(diào)一個反直覺的事實(shí)無信號的修復(fù)動作在發(fā)送端。按文檔給出的順序依次嘗試順序操作說明1打開發(fā)送端Transfer settings把bytes / frame 降到 1465默認(rèn) 2953 字節(jié)是為近距離手機(jī)對手機(jī)調(diào)優(yōu)的在臂長距離的普通顯示器上恰好是最容易失敗的配置2仍然無解把發(fā)送端tx fps 降到 24降低幀率給攝像頭更多曝光與對焦時間3讓接收畫面充滿整個取景框并把手機(jī)靠穩(wěn)/架住手持微顫導(dǎo)致的自動對焦來回搜索autofocus hunting是常見的元兇4把發(fā)送屏幕的亮度調(diào)到最高增加 QR 碼的對比度與信噪比注意順序不能跳先降密度bytes/frame再降速率tx fps。如果一上來就降 fps 而幀仍然過密問題依舊。1.3 源碼層面的證據(jù)建議值與下拉框的構(gòu)造性一致這些建議值不是文檔里隨手寫的數(shù)字而是與發(fā)送端 UI 共享的常量。見 shared/send-settings.tsexport const NO_SIGNAL_HINT_FRAME_BYTES 1465; export const NO_SIGNAL_HINT_TX_FPS 24;發(fā)送端的下拉選項(xiàng)TX_FPS_OPTIONS10 / 15 / 20 /24/ 30 / 55 /60與FRAME_BYTES_OPTIONS500 / 1000 /1465/ 1850 / 2331 /2953都以這兩個常量構(gòu)造而接收端無信號提示的文案也由同一批常量生成見 receive/main.ts。這意味著提示給出的建議值永遠(yuǎn)存在于發(fā)送端的下拉框里——不會出現(xiàn)建議設(shè)一個 UI 里根本不存在的數(shù)值這類脫節(jié)。文件頭注釋明確寫道無信號提示命中的兜底值來自這里因此建議不可能指向發(fā)送端不提供的設(shè)置。為什么默認(rèn)的 2953 字節(jié) / 60 fps 會在普通顯示器上失效shared/send-settings.ts 的注釋給出了關(guān)鍵約束一幀至少需要在屏幕上停留約 2 個刷新周期否則攝像頭捕獲會正好截到幀切換的瞬間在 60 Hz 屏幕上每幀恰好只獲得一個刷新周期早期實(shí)測捕獲率只有 0.20.4。所以默認(rèn)值是為 120 Hz 高刷發(fā)送端與近距離場景設(shè)計(jì)的最優(yōu)演示配置而非普適配置——這正是排障文檔把 1465 和 24 作為第一、第二修復(fù)手段的原因。選項(xiàng)中的 55 也刻意低于 60 Hz 天花板讓幀邊界在掃描過程中漂移而非騎在刷新時鐘上避免連續(xù)兩幀在同一位置撕裂。1.4 順帶提示幀大小與塊數(shù)上限的關(guān)系把 bytes/frame 調(diào)低要留意一個邊界幀頭用 u16 編號源塊上限 65535 塊MAX_SOURCE_BLOCKS 0xffff見 shared/frame-capacity.ts。因此文件大小上限并不總是 64 MB——在 500 字節(jié)/幀下真正的上限大約只有 30 MB。發(fā)送端會在開始傳輸前用fitsInOneStream()檢查若超限會明確報錯并給出把 bytes / frame 提高到某個值或以上的建議該建議值也一定在下拉框選項(xiàng)內(nèi)見 send/main.ts。也就是說調(diào)低幀密度既能修復(fù)無信號也可能觸發(fā)大文件的容量報錯兩者都是同一個機(jī)制在工作。二、Update the sending device / Update this app版本不匹配2.1 發(fā)生了什么當(dāng)接收端識別出這是 Decimen 流但我讀不了時會彈出上述兩條更新提示之一。其本質(zhì)是兩臺設(shè)備處于不同的線纜格式wire format上。Decimen 0.5.0 改變了幀格式與 0.4.x 不兼容——兩端必須都在 0.5.0 或更新版本上才能互通。2.2 提示的方向語義消息會指明落后的是哪一側(cè)按你看到的那條對號入座Update the sending device更新發(fā)送設(shè)備——落后的是屏幕那一端Update this app更新本應(yīng)用——落后的是你手里這臺手機(jī)。2.3 關(guān)鍵的單向啞火0.4.x 接收端對 0.5.0 發(fā)送端毫無反應(yīng)這兩條提示是 0.5.0新增的能力因此存在一個不對稱場景接收端停留在 0.4.x 或更早、發(fā)送端是 0.5.0 時接收端什么也顯示不出來——只有第一節(jié)的 Nothing happening? toast。原因是舊接收端根本不知道幀里還有個版本號字段。這正是 docs/technical/versioning.md 所講的版本化設(shè)計(jì)動機(jī)v1→v2 曾經(jīng)在格式變更上花了一次 magic 升級卻沒換來版本字段導(dǎo)致發(fā)送端太舊與光線不好看起來完全一樣從 v3隨 0.5.0 發(fā)布開始接收端必須能說出到底是以下哪一種情況判定含義接收端行為ok可解碼解碼foreign不是 Decimen 幀靜默攝像頭會看到視野內(nèi)每一個二維碼older-senderDecimen但格式更舊Update the sending device.newer-senderDecimen格式更新Update this app to receive it.unsupported-flagsDecimen帶本端無法實(shí)現(xiàn)的特性Update this app to receive it.malformed是我們的幀但自相矛盾靜默與壞讀取無法區(qū)分這套判定邏輯集中在 shared/protocol.ts 的classifyFrame()中屏幕文案則由frameVerdictMessage()統(tǒng)一生成shared/protocol.ts——它緊挨著格式定義存放正是為了判斷結(jié)果與提示文案永遠(yuǎn)不會漂移且任何客戶端網(wǎng)頁、未來的 iOS/Android對同一失敗都說同樣的話。雙 magic 字節(jié)0xD1 0xC3的作用是在說出任何版本信息之前先回答這到底是不是我們的幀——僅憑單個0xD1把關(guān)時約 1/256 的隨機(jī)二進(jìn)制 QR 載荷會誤入版本分支被錯誤地要求更新一臺從沒運(yùn)行過 Decimen 的設(shè)備兩個字節(jié)把關(guān)后誤報率從 0.402% 降到 0.006%。如果你確認(rèn)發(fā)送端已是最新、接收端卻依然失明先更新接收端。從 0.5.0 起兩端都能指名格式不匹配所以未來再發(fā)生格式變更時無論哪一端更舊接收屏幕上都會說清楚。另一種什么都不顯示的可能則是接收端在看根本不屬于 Decimen 的二維碼——這類情況故意保持靜默詳見第一節(jié)接收端會解碼視野里的每一個 QR 碼包括櫥窗和商品包裝上的。2.4 修復(fù)方法使用 decimen.app 托管站點(diǎn)在兩臺設(shè)備上重新加載頁面。如果某臺設(shè)備被安裝到了主屏幕PWA后仍提示不兼容徹底關(guān)閉應(yīng)用再重新打開以強(qiáng)制刷新 service worker 緩存。使用獨(dú)立單文件從舊版本保存下來的decimen-sender.html與decimen-receiver.html彼此可以永久互通但不能與更新版本的對方配合。需要從同一個發(fā)布版本重新下載兩者。詳細(xì)說明見 docs/user/install-and-offline.md——其中解釋了托管站點(diǎn)、兩個獨(dú)立文件、演示模式三種形態(tài)以及為什么獨(dú)立接收文件從file://打開時拿不到攝像頭見下文第三節(jié)。三、攝像頭問題選錯鏡頭、權(quán)限拒絕、非安全上下文3.1 選錯攝像頭前置/長焦有些手機(jī)會把錯誤的鏡頭當(dāng)作后置攝像頭交給瀏覽器導(dǎo)致畫面里要么是前置自拍要么是一支只有站到房間另一頭才清晰的長焦。修復(fù)方式Receive settings → camera在列表里選擇正確的鏡頭。注意兩點(diǎn)列表在攝像頭啟動后才顯示真實(shí)鏡頭名稱瀏覽器在授予權(quán)限前會隱藏鏡頭名切換立即生效傳輸中途也可以切換。3.2 權(quán)限被拒絕Permission denied瀏覽器彈出權(quán)限詢問時要點(diǎn)得仔細(xì)——如果不小心點(diǎn)了 Block需要到瀏覽器設(shè)置里為該站點(diǎn)允許攝像頭然后回到頁面點(diǎn)Start camera重新啟動無需刷新頁面。3.3 camera needs a secure context該報錯意味著頁面正通過明文 http提供服務(wù)。瀏覽器會在非安全來源上整體移除攝像頭 API。解決方式通過https提供服務(wù)——項(xiàng)目自帶的開發(fā)服務(wù)器就是 https自簽名證書或使用托管站點(diǎn) decimen.app。這正是 docs/user/quick-start.md 中npm run dev啟動的是 https 開發(fā)服務(wù)器的原因localhost是豁免的但你手機(jī)訪問的局域網(wǎng) IP 不是。3.4 獨(dú)立接收文件無法獲得攝像頭在 iOS 或 Android 上從file://直接打開decimen-receiver.html不會獲得攝像頭——本地文件拿到的是不透明來源opaque origin移動端瀏覽器不給本地文件提供相機(jī)權(quán)限。解決方式見 docs/user/install-and-offline.md把該文件放到任意 http(s) 服務(wù)器上供手機(jī)訪問或者改用托管站點(diǎn)的離線模式。發(fā)送端沒有這個問題decimen-sender.html在所有平臺都能從file://直接運(yùn)行。四、慢速傳輸調(diào)優(yōu)的兩個杠桿如果鏈路已經(jīng)建立幀能解出來但傳輸龜速問題就從能不能解轉(zhuǎn)為解多快。排障文檔指向 docs/user/sending.md 的調(diào)優(yōu)表——bytes/frame 和 tx fps 是唯二真正起作用的旋鈕設(shè)置默認(rèn)值說明tx fps60為 120 Hz 發(fā)送端調(diào)優(yōu)在 60 Hz 屏幕上如果接收端停滯降到 24–30bytes / frame2953QR v40密度天花板——近距離手機(jī)對手機(jī)很好對顯示器或遠(yuǎn)距離要回退到 1465v27error correctionLfountain 層已經(jīng)處理擦除丟幀L 在這些幀尺寸下是正確的取舍display size900 px受屏幕上限約束全屏模式忽略此值默認(rèn)值偏向最佳演示場景。若傳輸爬行按順序bytes/frame → 1465tx fps → 24——與第一節(jié)無信號的修復(fù)順序完全一致。需要理解的是幀內(nèi)糾錯QR 的 ECC與 fountain 層解決的是兩類不同問題前者應(yīng)對幀內(nèi)局部損壞corruption后者應(yīng)對整幀丟失erasure。在整幀解碼或丟棄 fountain 冗余的策略下L 級糾錯配合約 K·1.15 的冗余幀docs/technical/protocol.md才是這尺寸幀的最優(yōu)組合。五、快速定位速查表綜合以上四節(jié)把癥狀與修復(fù)手段收斂成一張速查表便于現(xiàn)場快速定位癥狀優(yōu)先懷疑修復(fù)攝像頭在跑一幀不解toast 彈出發(fā)送端配置過密/過快按序執(zhí)行bytes/frame → 1465 → tx fps → 24 → 穩(wěn)住手機(jī) → 拉滿亮度顯示Update the sending device接收端比發(fā)送端新更新發(fā)送端設(shè)備到 0.5.0顯示Update this app發(fā)送端比接收端新更新接收端到 0.5.0接收端毫無反應(yīng)且發(fā)送端已最新接收端是 0.4.x 或更舊 / 或在看非 Decimen 碼先更新接收端確認(rèn)視野中確實(shí)是 Decimen 流畫面是前置鏡頭或長焦模糊瀏覽器選錯鏡頭Receive settings → camera 切換可傳輸中途切換提示 permission denied誤點(diǎn) Block瀏覽器允許站點(diǎn)攝像頭點(diǎn) Start camera無需刷新提示需要安全上下文明文 http走 httpsdev server 已自帶自簽名證書或托管站點(diǎn)獨(dú)立接收文件拿不到攝像頭file://不透明來源放到 http(s) 服務(wù)器或使用托管站點(diǎn)離線模式詳見 docs/user/install-and-offline.md能解碼但很慢密度/速率失衡bytes/frame → 1465tx fps → 24按此順序結(jié)語先讀提示再動設(shè)置Decimen 的排障哲學(xué)可以濃縮為兩句靜默失敗比大聲失敗更糟糕所以 0.5.0 之后任何讀不了的 Decimen 流都會指名方向修復(fù)動作幾乎總在發(fā)送端所以 Nothing happening? 的 toast 指向的是另一臺設(shè)備上的兩個下拉框。從源碼看這兩條哲學(xué)都不是靠文檔約定而是被寫進(jìn)了常量共享shared/send-settings.ts、幀判定邏輯shared/protocol.ts與計(jì)時策略shared/no-signal.ts中。遇到問題時按本文速查表從前往后逐條嘗試多數(shù)情況下第 12 步就能讓畫面重新流動起來。贊分享前端通信【免費(fèi)下載鏈接】decimen-optical-transfer項(xiàng)目地址https://gitcode.com/gh_mirrors/de/decimen-optical-transfer點(diǎn)擊查看免費(fèi)下載相關(guān)推薦iTerm2 Python API 腳本排障實(shí)戰(zhàn)指南從 Script Console 到 Ladybug 的完整排查鏈路iTerm2 Python API 腳本排障實(shí)戰(zhàn)指南從 Script Console 到 Ladybug 的完整排查鏈路 iTerm2 提供了基于 Py桌面應(yīng)用AI 應(yīng)用Ray on KubernetesKubeRay排障指南從版本匹配到 Autoscaler 的實(shí)戰(zhàn)問題排查Ray on KubernetesKubeRay排障指南從版本匹配到 Autoscaler 的實(shí)戰(zhàn)問題排查 本文是基于 KubeRay 官方排障文檔 t人工智能分布式訓(xùn)練強(qiáng)化學(xué)習(xí)任務(wù)調(diào)度模型推理服務(wù)后端OneUptime RUM 故障排查實(shí)戰(zhàn)指南從 Token 校驗(yàn)到數(shù)據(jù)落盤的完整排障鏈路OneUptime RUM 故障排查實(shí)戰(zhàn)指南從 Token 校驗(yàn)到數(shù)據(jù)落盤的完整排障鏈路 導(dǎo)讀 本文是 OneUptime Real User Monitor可觀測性后端運(yùn)維前端云原生微服務(wù)AI Agent上一篇HCCL experimental/ 實(shí)驗(yàn)空間貢獻(xiàn)指南目錄規(guī)范、運(yùn)行期開關(guān)與維護(hù)策略全解析下一篇new-api 計(jì)費(fèi)表達(dá)式系統(tǒng)billingexpr全解析一行表達(dá)式定義完整計(jì)費(fèi)邏輯創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考