在與來自烏克蘭github大大來信後，他推薦我用WebRTC方式，最後進行串流討論後得出以下結論

我覺得WebRTC預設編碼的x264,本身好像也是p2p??,雖然延遲性和安全性提高了但是在應付大規模場景下應該不適合，

别迷信 WebRtc，WebRtc只适合小范围（8人以内）音视频会议，不适合做直播：
1. 视频部分：vpx的编码器太弱，专利原因不能用264，做的好的都要自己改264/265代码才行。
2. 音频部分：音频只适合人声编码，对音乐和其他非人声的效果很糟糕。
3. 网络部分：对国内各种奇葩网络适应性太低，网络糟糕点或者人多点就卡。
4. 信号处理：同时用过 GIPS和 WebRTC 进行对比，可以肯定目前开源的代码是GIPS阉割过的。
5. 使用规模：10人以内使用，超过10人就挂了，WebEx方案支持的人数都比 RTC 强。

作者：韦易笑
链接：https://www.zhihu.com/question/25497090/answer/72397450
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

在我詢問他是否可以通過我在上回的方向去實作他說是可行的(基於商業客戶向他買解決方案)不能透漏，在分支

https://github.com/Kukunin/ffmpeg.js/commit/acca0c151807d88bddd73e885a183750bd793246#diff-b67911656ef5d18c4ae36cb6741b7965R347

提到這個部分大概就可以解決我所說的問題，再來就是猜猜看怎麼處理了

在ffmpeg 轉成 ffmpeg.js 他在把 ffmpeg 裡面的 file 和 tcp 的函數裡面的意外中斷的片段程式碼

都給 remark掉這樣在運行 async stdio就不會意外中止 ( 或許就可以向他說的透過 getUserMedia 去讀取資料這樣我們只要把那些blob 轉成 file 跟原先一樣不用動，在結合上一個文章就可以達到用網路傳遞數據給後端推送給其他串流伺服器了前端編碼就完成囉!

再來就是要再編譯的參數 EMTERPRETIFY_ASYNC=1 給打開

他fork出來額外新增的內容應該就是這些

提到他說可以從這方向找尋到我要的解答所以確定可以用getUesrMedia去實作還有以下要問題要解決
第一個就是blob跟輸出檔案問題一樣超過70mb可能會出現記憶體崩潰或者溢位導致瀏覽器crash
可能要查閱 wasm fs 虛擬檔案映射那邊
第二個則是檔案的讀入方式

他提問我為什麼要用自定義ffmpeg 去做影音上的串流，目前不是有 WebRTC可以達成目標了嗎
我當初想做是因為可以實現任意編碼的問題和可以隨意推送去任意 RTMP串流伺服器，再者就是目前大部分主流是RTMP 又有豐富的 CDN 當然 WebRTC也可以實作CDN ，國外網友好像不怎麼贊成好像不太怎麼穩定)
上述內容可能需要重新compliter 整個 ffmpeg.js才能實證了，又是一個17小時?，有空再來玩 (話說是不是該刷leetcode了