制作了一個程序，通過標題將PNG圖像流式傳輸?shù)綖g覽器，我注意到標簽中只顯示倒數(shù)前的幀，而不是最近發(fā)送的幀。multipart/x-mixed-replaceContent-Type<img>這種行為非常煩人，因為我僅在圖像更改時發(fā)送更新以節(jié)省帶寬，這意味著在我等待更新時屏幕上會出現(xiàn)錯誤的幀。具體來說，我正在使用Brave瀏覽器（基于chromium），但是由于我已經(jīng)嘗試了上下兩個“shields”，因此我認為至少在其他基于chromium的瀏覽器中也會出現(xiàn)此問題。搜索問題只產(chǎn)生一個相關(guān)結(jié)果（以及許多不相關(guān)的結(jié)果），即這個HowToForge線程，沒有回復。同樣，我也認為問題與緩沖有關(guān)，但我確保刷新緩沖區(qū)無濟于事，這與線程中的用戶非常相似。用戶確實報告說它在他們的一個服務器上工作，而不是在另一個服務器上工作，這使我相信它可能與特定的HTTP標頭或類似的東西有關(guān)。我的第一個猜測是因為瀏覽器可以從中分辨出圖像何時完成，但它似乎沒有任何影響。Content-Length所以從本質(zhì)上講，我的問題是：有沒有辦法告訴瀏覽器顯示最新的多部分/ x-mixed-replace而不是之前的那個？而且，如果這不是標準行為，原因可能是什么？當然，這是相關(guān)的源代碼，盡管我認為這更像是一個通用的HTTP問題，而不是與代碼有關(guān)的問題：
3 回答
守著星空守著你
TA貢獻1799條經(jīng)驗 獲得超8個贊
多部分 MIME 郵件中的部分以 MIME 標頭開頭，以邊界結(jié)尾。在第一個實部之前有一個邊界。此初始邊界關(guān)閉了 MIME 前導碼。
相反，您的代碼假定部件以邊界開頭?；诖思僭O(shè)，首先發(fā)送邊界，然后發(fā)送 MIME 標頭，然后發(fā)送 MIME 正文。然后停止發(fā)送，直到下一部分準備就緒。因此，只有在發(fā)送下一個部件后，才會檢測到一個部件的末端，因為只有這樣，您才會發(fā)送前一個部件的結(jié)束邊界。
若要解決此問題，代碼最初應發(fā)送一個邊界來結(jié)束 MIME 前導碼。然后，對于每個新部件，它應發(fā)送 MIME 標頭、MIME 正文，然后發(fā)送邊界以結(jié)束此部件。
嗶嗶one
TA貢獻1854條經(jīng)驗 獲得超8個贊
我有同樣的問題：使用時有1幀延遲multipart/x-mixed-replace
這個問題似乎出現(xiàn)在Chrome中，它似乎與Chrome不再支持資源的事實有關(guān)。此問題在 Firefox 中不存在。multipart/x-mixed-replace
因此，“誘騙”Chrome顯示視頻流的唯一方法是將每個圖像發(fā)送兩次或接受1幀延遲。如前所述，問題在Firefox中不存在。
慕沐林林
TA貢獻2016條經(jīng)驗 獲得超9個贊
這是Chrome的一個問題。在Firefox中，它按預期工作。
我通過以下方式解決了這個問題C# example
var chromeWorkaround = Encoding.UTF8.GetBytes($"\r\n--{Boundary}\r\n\r\n--{Boundary}\r\n");將其附加到您的流中，它似乎會強制鑲邊立即呈現(xiàn)。
我在這里報告了：https://bugs.chromium.org/p/chromium/issues/detail?id=1250396
- 3 回答
- 0 關(guān)注
- 134 瀏覽
添加回答
舉報
0/150
提交
取消