丟包重傳: 當接收方發生丟包，如果丟包的時刻 T1 + rtt_var< 接收方當前的時刻 T2，就認爲是丟包了，這個時候就會把所有滿足這個條件丟失的報文 ID 構建一個NACK反饋給發送方，發送方收到這個反饋根據 ID 到重發窗口緩衝區中查找對應的報文重發即可。服務器端直到緩衝區裏的包都未丟包時，才寫入文件，APP端同理。該方法的缺點是增大了端到端的延遲，尤其在丟包大量發生時更爲明顯(嵌入式端影響不大)。前向糾錯FEC ，該方法的優點是視頻無延遲，但發送冗餘包占用了額外的帶寬資源。更爲可行的方案是是混合NACK／FEC模式。(服務器端、嵌入式端、APP端)
亂序: 可以根據RTP包的序列號來排序, 創建一個接收緩存，先排序，後寫入文件。(服務器端、APP端)
同步: 根據聲音流和圖像流的相對時間（即RTP包的時間戳），以及它們的絕對時間（即對應的RTCP包中的RTCP），可以實現聲音和圖像的同步。(APP端)
碼率控制: Google Congestion Control，簡稱GCC。GCC算法是一種混合了基於丟包和基於時延的方法，原理如下：a、發送端根據丟包調整目標帶寬，具體來說：低丟包率（小於2%）時增加目標碼率，高丟包率（大於10%）時減小目標碼率，丟包率介於二者之間時目標碼率保持不變； b、接收端根據時延估計最大帶寬，由三個模塊組成：排隊時延估計、鏈路過載檢測和最大帶寬估計模塊，三個模塊間的關係爲：當排隊時延小於閾值（根據網絡狀態自適應調整）時，鏈路檢測結果爲underuse；當排隊時延大於閾值時，鏈路檢測結果爲overuse；介於二者之間時，鏈路檢測結果爲normal；最大帶寬估計模塊的實現是一個表示當前鏈路狀態（Increase、Hold、Decrease）的有限狀態機，初始狀態爲Hold，根據鏈路檢測結果進行狀態遷移，並根據遷移後的鏈路狀態和當前接收碼率估計最大帶寬remb。
APP端通過RTCP REMB反饋到發送端，發送端最終的目標碼率應不超過remb值。服務器端通過以下方法降低碼率：1、降低發送速度 2、有選擇的丟棄數據包，例如P幀(服務器端、APP端)
秒開畫面： 服務器每次以最快的速度一次性發送10秒的內容，APP先將10秒的內容(10*20/s = 200幀)緩存下來，邊緩存邊播放，當播放到還剩2秒的時候再向服務器發送請求(RTSP PLAY)，服務器繼續發送下一個10秒的內容。(服務器端、APP端)