我真的很想了解使用node.js將ffmpeg實時輸出流到HTML5客戶端的最佳方法，因為有很多變量在起作用，而且我在這個領(lǐng)域沒有很多經(jīng)驗，花了很多小時嘗試不同的組合。我的用例是：1）IP攝像機RTSP H.264流由FFMPEG采集，并使用節(jié)點中的以下FFMPEG設(shè)置重新混合到mp4容器中，并輸出到STDOUT。這僅在初始客戶端連接上運行，因此部分內(nèi)容請求不會嘗試再次產(chǎn)生FFMPEG。2）我使用節(jié)點http服務(wù)器捕獲STDOUT并根據(jù)客戶端請求將其流式傳輸回客戶端。當客戶端第一次連接時，我產(chǎn)生了上面的FFMPEG命令行，然后將STDOUT流通過管道傳遞到HTTP響應(yīng)。我使用以下HTTP標頭（在流式傳輸預先記錄的文件時也使用并起作用）3）客戶端必須使用HTML5視頻標簽。我沒有流傳輸回放的問題（使用fs.createReadStream和206 HTTP部分內(nèi)容）到HTML5客戶端，該視頻文件以前是使用上述FFMPEG命令行記錄的（但保存到文件而不是STDOUT），所以我知道FFMPEG流是正確的，甚至在連接到HTTP節(jié)點服務(wù)器時，我什至可以在VLC中正確看到視頻直播。但是，嘗試通過節(jié)點HTTP從FFMPEG進行實時流傳輸似乎要困難得多，因為客戶端將顯示一幀然后停止。我懷疑問題是我沒有將HTTP連接設(shè)置為與HTML5視頻客戶端兼容。我已經(jīng)嘗試了多種方法，例如使用HTTP 206（部分內(nèi)容）和200個響應(yīng)，將數(shù)據(jù)放入緩沖區(qū)中，然后在沒有運氣的情況下進行流式傳輸，因此，我需要回到第一個原則，以確保將其正確設(shè)置道路。這是我對這應(yīng)該如何工作的理解，如果我錯了，請糾正我：1）應(yīng)該設(shè)置FFMPEG來分割輸出并使用一個空的moov（FFMPEG frag_keyframe和empty_moov mov標志）。這意味著客戶端不會使用moov原子，該原子通常位于文件末尾，而在流傳輸時無關(guān)緊要（文件末尾），但是這意味著沒有可能的查找，這對我的用例來說很好。2）即使我使用MP4片段和空白的MOOV，我仍然必須使用HTTP部分內(nèi)容，因為HTML5播放器將等到整個流下載完畢后再播放，而實時流永遠不會結(jié)束，因此無法使用。3）我不明白為什么在實時流式傳輸時將STDOUT流傳輸?shù)紿TTP響應(yīng)為什么仍然不起作用，如果我保存到文件中，則可以使用類似的代碼輕松地將此文件流式傳輸?shù)紿TML5客戶端。也許這是一個定時問題，因為FFMPEG生成需要一秒鐘才能啟動，連接到IP攝像機并將塊發(fā)送到節(jié)點，并且節(jié)點數(shù)據(jù)事件也不規(guī)則。但是，字節(jié)流應(yīng)與保存到文件完全相同，并且HTTP應(yīng)該能夠應(yīng)付延遲。4）當從相機流式傳輸FFMPEG創(chuàng)建的MP4文件時，從HTTP客戶端檢查網(wǎng)絡(luò)日志時，我看到有3個客戶端請求：對視頻的常規(guī)GET請求，HTTP服務(wù)器返回大約40Kb，然后是部分內(nèi)容請求，其字節(jié)范圍為文件的最后10K，然后最終請求為中間的位未加載。也許HTML5客戶端一旦收到第一個響應(yīng)，便要求文件的最后部分加載MP4 MOOV原子？如果是這種情況，將無法進行流式傳輸，因為沒有MOOV文件，也沒有文件結(jié)尾。5）在嘗試實時流式傳輸時檢查網(wǎng)絡(luò)日志時，我收到了一個中止的初始請求，僅收到了200個字節(jié)，然后再次發(fā)出了200字節(jié)的中止請求，而第三個請求的長度只有2K。我不明白為什么HTML5客戶端會中止請求，因為字節(jié)流與從記錄的文件流式傳輸時可以成功使用的字節(jié)流完全相同。似乎節(jié)點也沒有將其余的FFMPEG流發(fā)送到客戶端，但是我可以在.on事件例程中看到FFMPEG數(shù)據(jù)，因此它正在到達FFMPEG節(jié)點HTTP服務(wù)器。6）盡管我認為將STDOUT流傳輸?shù)紿TTP響應(yīng)緩沖區(qū)應(yīng)該可以，但是我是否必須構(gòu)建一個中間緩沖區(qū)和流，以允許HTTP部分內(nèi)容客戶端請求像正常（成功）讀取文件時一樣正常工作？我認為這是我遇到問題的主要原因，但是我不確定在Node中如何最好地進行設(shè)置。而且我不知道如何在文件末尾處理客戶端對數(shù)據(jù)的請求，因為沒有文件末尾。7）我在嘗試處理206個部分內(nèi)容請求時走錯了軌道，并且這應(yīng)該在正常的200個HTTP響應(yīng)下起作用嗎？HTTP 200響應(yīng)對于VLC可以正常工作，因此我懷疑HTML5視頻客戶端僅適用于部分內(nèi)容請求嗎？由于我仍在學習這些東西，因此很難解決該問題的各個層次（FFMPEG，節(jié)點，流，HTTP，HTML5視頻），因此任何指針將不勝感激。我已經(jīng)花了數(shù)小時在此站點和網(wǎng)絡(luò)上進行研究，但我還沒有遇到能夠在節(jié)點中進行實時流式傳輸?shù)娜魏稳?，但我不能成為第一個，而且我認為這應(yīng)該可以工作（以某種方式?。?。