RTMP直播應用與延時分析
HLS主要是延時比較大，RTMP主要優勢在於延時低。
一、應用場景
低延時應用場景包括：. 互動式直播：譬如2013年大行其道的美女主播，遊戲直播等等
各種主播，流媒體分發給使用者觀看。使用者可以文字聊天和主播互動。
. 視訊會議：我們要是有同事出差在外地，就用視訊會議開內部會議。
其實會議1秒延時無所謂，因為人家講完話後，其他人需要思考，
思考的延時也會在1秒左右。當然如果用視訊會議吵架就不行。
. 其他：監控，直播也有些地方需要對延遲有要求，
網際網路上RTMP協議的延遲基本上能夠滿足要求。
二、RTMP和延時
1. RTMP的特點如下：
1) Adobe支援得很好：RTMP實際上是現在編碼器輸出的工業標準協議，基本上所有的編碼器（攝像頭之類）都支援RTMP輸出。
原因在於PC市場巨大，PC主要是Windows，Windows的瀏覽器基本上都支援flash，
Flash又支援RTMP支援得非常好。
2) 適合長時間播放：
因為RTMP支援的很完善，所以能做到flash播放RTMP流長時間不斷流，
當時測試是100萬秒，即10天多可以連續播放。
對於商用流媒體應用，客戶端的穩定性當然也是必須的，否則終端使用者看不了還怎麼玩？
我就知道有個教育客戶，最初使用播放器播放http流，需要播放不同的檔案，結果就總出問題，
如果換成伺服器端將不同的檔案轉換成RTMP流，客戶端就可以一直播放；
該客戶走RTMP方案後，經過CDN分發，沒聽說客戶端出問題了。
3）延遲較低：
比起YY的那種UDP私有協議，RTMP算延遲大的（延遲在1-3秒），
比起HTTP流的延時（一般在10秒以上）RTMP算低延時。
一般的直播應用，只要不是電話類對話的那種要求，RTMP延遲是可以接受的。
在一般的視訊會議應用中，RTMP延時也能接受，原因是別人在說話的時候我們一般在聽，
實際上1秒延時沒有關係，我們也要思考（話說有些人的CPU處理速度還沒有這麼快）。
4) 有累積延遲：
技術一定要知道弱點，RTMP有個弱點就是累積誤差，原因是RTMP基於TCP不會丟包。
所以當網路狀態差時，伺服器會將包快取起來，導致累積的延遲；
待網路狀況好了，就一起發給客戶端。
這個的對策就是，當客戶端的緩衝區很大，就斷開重連。
2. HLS低延時
主要有人老是問這個問題，如何降低HLS延遲。HLS解決延時，就像是爬到楓樹上去捉魚，奇怪的是還有人喊，看那，有魚。
你說是怎麼回事?
我只能說你在參與謙哥的魔術表演，錯覺罷了。
如果你真的確信有，請用實際測量的圖片來展示出來，參考下面延遲的測量。
3. RTMP延遲的測量
如何測量延時，是個很難的問題，不過有個行之有效的方法，就是用手機的秒錶，可以比較精確的對比延時。
經過測量發現，在網路狀況良好時：
. RTMP延時可以做到0.8秒左右。
. 多級邊緣節點不會影響延遲（和SRS同源的某CDN的邊緣伺服器可以做到）
. Nginx-Rtmp延遲有點大，估計是快取的處理，多程序通訊導致？
. GOP是個硬指標，不過SRS可以關閉GOP的cache來避免這個影響.
. 伺服器效能太低，也會導致延遲變大，伺服器來不及傳送資料。
. 客戶端的緩衝區長度也影響延遲。
譬如flash客戶端的NetStream.bufferTime設定為10秒，那麼延遲至少10秒以上。
4. GOP-Cache
什麼是GOP？就是視訊流中兩個I幀的時間距離。GOP有什麼影響？
Flash（解碼器）只有拿到GOP才能開始解碼播放。
也就是說，伺服器一般先給一個I幀給Flash。
可惜問題來了，假設GOP是10秒，也就是每隔10秒才有關鍵幀，
如果使用者在第5秒時開始播放，會怎麼樣？
第一種方案：等待下一個I幀，
也就是說，再等5秒才開始給客戶端資料。
這樣延遲就很低了，總是實時的流。
問題是：等待的這5秒，會黑屏，現象就是播放器卡在那裡，什麼也沒有，
有些使用者可能以為死掉了，就會重新整理頁面。
總之，某些客戶會認為等待關鍵幀是個不可饒恕的錯誤，延時有什麼關係？
我就希望能快速啟動和播放視訊，最好開啟就能放！
第二種方案：馬上開始放，
放什麼呢？
你肯定知道了，放前一個I幀。
也就是說，伺服器需要總是cache一個gop，
這樣客戶端上來就從前一個I幀開始播放，就可以快速啟動了。
問題是：延遲自然就大了。
有沒有好的方案？
有！至少有兩種：
編碼器調低GOP，譬如0.5秒一個GOP，這樣延遲也很低，也不用等待。
壞處是編碼器壓縮率會降低，影象質量沒有那麼好。
5. 累積延遲
除了GOP-Cache，還有一個有關係，就是累積延遲。伺服器可以配置直播佇列的長度，伺服器會將資料放在直播佇列中，
如果超過這個長度就清空到最後一個I幀：
當然這個不能配置太小，
譬如GOP是1秒，queue_length是1秒，這樣會導致有1秒資料就清空，會導致跳躍。
有更好的方法？有的。
延遲基本上就等於客戶端的緩衝區長度，因為延遲大多由於網路頻寬低，
伺服器快取後一起發給客戶端，現象就是客戶端的緩衝區變大了，
譬如NetStream.BufferLength=5秒，那麼說明緩衝區中至少有5秒資料。
處理累積延遲的最好方法，是客戶端檢測到緩衝區有很多資料了，如果可以的話，就重連伺服器。
當然如果網路一直不好，那就沒有辦法了。
相關推薦
RTMP直播應用與延時分析
直播應用中，RTMP和HLS基本上可以覆蓋所有客戶端觀看，HLS主要是延時比較大，RTMP主要優勢在於延時低。 一、應用場景 低延時應用場景包括： . 互動式直播：譬如2013年大行其道的美女主播，遊戲直播等等 各種主播，流媒體分發給使用者觀看。使用者可以文字聊天和主播互動。 . 視訊會議：
20190110 貝加萊PLC C語言迴圈與延時應用
void _CYCLIC ProgramCyclic(void) { if(B) { i; TON_10ms(&T1); switch (i) { case 0: T1.IN=1; T1.PT=100;//delay 1s if(T1.Q) { T1.IN=0; i+=1; } br
定時與延時任務
定時 延時 任務 一、延時任務 atd 服務linux 下一次性定時計劃任務命令的守候進程，是一種開機自啟的服務 at命令是在atd服務開啟的情況下才可以進行操作，否則會出現報錯。 at類似打印進程，會把任務放到/var/spool/at目錄中，到指定時間運行它 。at命令相當於另一
linux基礎篇（七）：基於Redhat7系統的系統日誌與延時任務
系統日誌 配置檔案： /etc/rsyslog.conf 系統日誌是記錄系統中硬體、軟體和系統問題的資訊，同時還可以監視系統中發生的事件。使用者可以通過它來檢查錯誤發生的原因，或者尋找受到攻擊時攻擊者留下的痕跡。 常用日誌型別與日誌級別 型別 auth
Redis 非同步訊息佇列與延時佇列
訊息中介軟體，大家都會想到 Rabbitmq 和 Kafka 作為訊息佇列中介軟體，來給應用程式之間增加非同步訊息傳遞功能。這兩個中介軟體都是專業的訊息佇列中介軟體，特性之多超出了大多數人的理解能力。但是這種屬於重量級的應
運維學習 unit 16 定時任務與延時任務
一.延時任務命令at 1 at命令兩種開啟方式 1）at +時間 編輯命令， 以touch /mnt/test 為例 2）at now+1min 檢視延遲任務at -l 檢視任務內容、 at -c +任務號 刪除延時任務 at -r +任務號 2 a
FreeRTOS（21）---FreeRTOS 系統延時分析
FreeRTOS 系統延時分析 FreeRTOS 系統延時分析 相對延時函式vTaskDelay() 絕對延時函式vTaskDelayUntil() 小結 FreeRTOS 系統延時分析 FreeRTOS
定時器與延時函式
STM32定時器包含基本定時器、通用定時器和高階定時器，其中TIM6和TIM7是STM32當中的基本定時器，作為初學者，先從最基本的學起最容易，下面我們用這個定時器實現毫秒延時函式來入門STM32定時器的應用。學習微控制器，就是學習使用它的暫存器。即便你用庫函式，暫存器也是必
美團技術團隊 Quartz應用與叢集原理分析
一、問題背景 美團CRM系統中每天有大量的後臺任務需要排程執行，如構建索引、統計報表、週期同步資料等等，要求任務排程系統具備高可用性、負載均衡特性，可以管理並監控任務的執行流程，以保證任務的正確執行。 二、歷史方案 美團CRM系統的任務排程模組經歷了以下歷史方案。 1. C
C++11新特性應用--實現延時求值(std::function和std::bind)
說是延時求值，注意還是想搞一搞std::function和std::bind。 現在就算是補充吧，再把std::bind進行討論討論。 何為Callable Objects？ 即可呼叫物件，比如函式指標、仿函式、類成員函式指標等都可稱為可呼叫物件。
頻寬與延時知識整理
一直以來對頻寬和時延的計算都迷迷糊糊，今天做了一個簡單的整理。 基礎 首先弄清楚幾個概念：訊號佔用頻寬、資料傳輸速率(位元率)、波特率、通道頻寬 訊號的誤區：0101、0110 等等，這些不是訊號（是訊息）。訊號是實實在在的波形，方波、正弦波等。
MySQL 複製滯後與延時複製
1：MySQL 複製滯後解決 MySQL複製被普遍認為是十分有效的，主伺服器進行更改後，從伺服器可在幾秒內做出相應的改動。但如果發生兩者之間同步緩慢的問題， 那麼主要有以下兩個原因： 從結點磁碟問題： 複製操作對每個資料庫都是由一個執行緒來完成，通常執行變更
RabbitMQ高階之訊息限流與延時佇列
>人生終將是場單人旅途，孤獨之前是迷茫，孤獨過後是成長。 ## 楔子 本篇是訊息佇列`RabbitMQ`的第五彈。 上篇本來打算講述`RabbitMQ`的一些高階用法： * 如何保證訊息的可靠性？ * 訊息佇列如何進行限流？ * 如何設定延時佇列進行延時消費？ 最終因為篇幅緣故，上篇只講了`
低延時的RTMP網絡直播
流媒體系統 網絡直播 低延時 rtmp直播 800li media server 互聯網時代的直播需求越來越多，觀看直播的人群對直播的要求也越來越高。在百度或谷歌等搜索引擎裏輸入關鍵詞“網絡直播延時”，大家的疑問不少： ü 什麽軟件看直播無延遲？ü 為什麽網絡直播與電視直播有大概2分鐘的延
分析一下H5直播、微信直播、抓娃娃、低延時的方案
毫秒 nginx 支持 rtmp 前端 延遲 時長 左右 html 微信直播,HTML5直播,主要方案有如下幾種： 1,基於hls切片直播，前前是應用的主流,服務器可以選fms,wowza,nginx,srs之類 優點：集成方便，支持度高，兼容性好，主流手都支持，是目前直播
各種RTMP直播流播放許可權_音視訊_資料花屏_問題檢測與分析工具EasyRTMPClient
之前的一篇部落格《網路攝像機IPCamera RTSP直播播放網路/許可權/音視訊資料/花屏問題檢測與分析助手EasyRTSPClient》，我們介紹了RTSP流的檢測和分析工具EasyRTSPClient，可以說已經是深入了我的平時運維工作中了，當我們發現有任
直播疑難雜癥排查（4）— 延時高
直播 問題 延時 排查 測量 本文是 《直播疑難雜癥排查》系列的第四篇文章，我們來看看直播的延時問題。1. 延時的測量一般測量延時最簡單的方法，就是推流端和播放端對著同一個時鐘，然後用播放端顯示的時間減去推流端顯示的時間，就得到了粗略的直播延時。2. 延時高問題分析首先，我們看看可能產生延
CentOS7.2通用二進制格式安裝mariadb-5.5.46-linux-x86_64.tar.gz文檔與啟動時失敗排查分析
centos7.2通用二進制格式安裝mariadb-5.5.46-linux-x86_64.tar.gzCentOS7.2通用二進制格式安裝mariadb-5.5.46-linux-x86_64.tar.gz提前準備好mariadb-5.5.46-linux-x86_64.tar.gz[[email
mysql並行復制降低主從同步延時的思路與啟示
sequence 影響 並行 修改 同步時間 就是 讀寫 技術分享 relay 一、緣起 mysql主從復制，讀寫分離是互聯網用的非常多的mysql架構，主從復制最令人詬病的地方就是，在數據量較大並發量較大的場景下，主從延時會比較嚴重。 為什麽mysql主從延時這麽大？
用微信小程序來做直播，效果非常不錯哦，延時低（組圖）
拓展 tro water align div csdn 手機瀏覽器 問題 分享圖片 第1部分：大至描述 用微信小程序來發起直播（推流）； 用戶即可以通過微信直接觀看，也可以通過PC端web瀏覽器觀看或通過手機瀏覽器觀看。 第2部分：提示說明 圖1，是小程序界面方面的