優化編碼延遲
編碼器延遲主要優化方式有：
去除B幀，目前Android編碼器基本都是 H264 Baseline 配置，沒有啓動B幀編碼。
另外Android 最新 API 多了 MediaFormat.KEY_LATENCY 編碼參數，在平臺上有沒有用，目前資料比較少，不太清楚。
優化網絡延遲
通過抓包發現，網絡上數據包存在週期性脈衝輸出流量，懷疑網絡傳輸中存在小報文拼接批量傳輸的行爲，不利於投屏實時性。
排查發現HTTP服務庫基於HTTP/1.1協議實現，啓用了chunked傳輸方式，組裝chunk存在拼接行爲，通過flush OutputStream可以立即發送一個chunk。
另外TCP協議默認開啓了Nagle算法，也會存在緩存下來延遲發送的因爲，需要打開 TCP_NODELAY 開關。但是目前用的HTTP服務實現庫沒有設置接口，暫沒有實施。
優化解封裝延遲
ffplay/ffmpeg 解封裝需要探測封裝格式，子流信息。
這些可以直接設置，不需要提測
ffplay -f h264 -framerate 60
另外調試發現，ffplay 在 read_thread 上 find_stream_info 花了很長時間，可以關閉
ffplay -f h264 -framerate 60 -nofind_stream_info
優化解碼延遲
調試發現在從讀取到第一個 Packet，到渲染出第一幀，有2~3秒時間（幀率較小 fps=1）。
無意中找到 -flags low_delay，用了一下基本感覺不到延遲了。具體的機制網上資料比較少，ffmpeg也沒有相關文檔說明，還有待進一步研究。
ffplay -f h264 -framerate 60 -nofind_stream_info -flags low_delay
優化渲染延遲
上面將 framerate 設置爲很大的數值 60，就是讓渲染延遲變小，即使因爲抖動引起了延遲，但是因爲播放幀率大於輸出幀率，播放輸出較快，還會追上。