前言：音視訊中一些基礎問題總結，哈哈，可在下方留言，一句話，證明你是接觸音視訊開發的。下面是我的一些整理及工作中整理的，不見得全是對的，可以大膽的指出的。我也好學習學習。

　　1、視訊編碼標準兩大系統是什麼?

　　視訊編碼標準有兩大系統：MPEG和ITU-T，如下

　　視訊編碼標準

　　MPEG標準由MPEG制定

　　MPEG-1 | MPEG-2 | (MPEG-3) | MPEG-4 | MPEG-7 | MPEG-21

　　ITU-T標準由VCEG制定

　　H.261 | (H.262) | H.263 | H.263v2 | H.264

　　2、什麼是音視訊編碼格式?什麼是音視訊封裝格式?

　　常見的AVI、RMVB、MKV、ASF、WMV、MP4、3GP、FLV等檔案其實只能算是一種封裝標準。

　　一個完整的視訊檔案是由音訊和視訊2部分組成的。H264、Xvid等就是視訊編碼格式，MP3、AAC等就是音訊編碼格式。

　　例如：將一個Xvid視訊編碼檔案和一個MP3視訊編碼檔案按AVI封裝標準封裝以後，就得到一個AVI字尾的視訊檔案，這個就是我們常見的AVI視訊檔案了。

　　由於很多種視訊編碼檔案、音訊編碼檔案都符合AVI封裝要求，則意味著即使是AVI字尾，也可能裡面的具體編碼格式不同。因此出現在一些裝置上，同是AVI字尾檔案，一些能正常播放，還有一些就無法播放。

　　同樣的情況也存在於其他容器格式。即使RMVB、WMV等也不例外，事實上，很多封裝容器對音訊編碼和視訊編碼的組合方式放的很開，如AVI還可以使用H.264+AAC組合，可以在具體使用中自己體會。尤其是MKV封裝容器，基本無論什麼樣的組合都可以!但一般MKV用的最多的就是H.264+AAC組合，此組合檔案體積最小，清晰度最高。因此網上很多MKV視訊都是高清晰度的。

　　因此，視訊轉換需要設定的本質就是：A設定需要的視訊編碼、B設定需要的音訊編碼、C選擇需要的容器封裝。一個完整的視訊轉換設定都至少包括了上面3個步驟。

　　3、平時說的軟解和硬解，具體是什麼?

　　硬解就是硬體解碼，指利用GPU來部分代替CPU進行解碼，軟解就是軟體解碼，指利用軟體讓CPU來進行解碼。兩者的具體區別如下所示：

　　硬解碼：是將原來全部交由CPU來處理的視訊資料的一部分交由GPU來做，而GPU的並行運算能力要遠遠高於CPU，這樣可以大大的降低對CPU的負載，CPU的佔用率較低了之後就可以同時執行一些其他的程式了，當然，對於較好的處理器來說，比如i5 2320，或者AMD 任何一款四核心處理器來說，硬解和軟體的區別只是個人偏好問題了吧。

　　軟解碼：即通過軟體讓CPU來對視訊進行解碼處理;而硬解碼：指不借助於CPU，而通過專用的子卡裝置來獨立完成視訊解碼任務。曾經的VCD/DVD解壓卡、視訊壓縮卡等都隸屬於硬解碼這個範疇。而現如今，要完成高清解碼已經不再需要額外的子卡，因為硬解碼的模組已經被整合到顯示卡GPU的內部，所以目前的主流顯示卡(集顯)都能夠支援硬解碼技術。

　　4、何為直播?何為點播?

　　直播：是一個三方互動(主播、伺服器、觀眾)，這個互動式實時的!儘管會根據選擇的協議不同而有一些延遲，但我們仍認為它直播是實時的!--->主播在本地傳送音視訊給伺服器(推流)，觀眾從伺服器實時解碼(拉流)收看收聽主播發送給伺服器的音視訊(直播內容)。直播是不能快進的

　　點播：首先一定要明確的一點，點播不存在推流這一過程，你本身你的流已經早就推給伺服器了，或者這麼說也不對，應該是你的音視訊早就上傳到了伺服器，觀眾只需要線上收看即可，由於你的音視訊上傳到了伺服器，觀眾則可以通過快進，快退，調整進度條等方式進行收看!

　　5、簡述推流、拉流的工作流程?

　　推流：在直播中，一方向伺服器傳送請求，向伺服器推送自己正在實時直播的資料，而這些內容在推送到伺服器的這一過程中是以 “流” 的形式傳遞的，這就是“推流”，把音視訊資料以流的方式推送(或上傳)到伺服器的過程就是“推流”!推流方的音視訊往往會很大，在推流的過程中首先按照 aac音訊-編碼 和 h264視【公眾平臺不能出現視訊這兩個字，真是坑】頻-編碼的標準把推過來的音視訊壓縮 ，然後合併成 MP4或者 FLV格式，然後根據直播的封裝協議，最後傳給伺服器完成推流過程。

　　拉流：與推流正好相反，拉流是使用者從伺服器獲取推流方給伺服器的音視訊的過程，這就是“拉流”!拉流首先aac音訊-解碼 和 h.264視【公眾平臺不能出現視訊這兩個字，真是坑】 頻-解碼的內部把推過來的音視訊解壓縮，然後合成 MP4或者 FLV 格式，再解封裝，最後到我們的客戶端與觀眾進行互動。

　　6、常見的直播協議有哪些?之間有什麼區別?

　　常見的直播協議有三種 RTMP、HLS、FLV...

　　1、RTMP：real time messaging protocol~實時傳輸協議，RTMP協議比較全能，既可以用來推送又可以用來直播，其核心理念是將大塊的視訊幀和音訊幀“剁碎”，然後以小資料包的形式在網際網路上進行傳輸，而且支援加密，因此隱私性相對比較理想，但拆包組包的過程比較複雜，所以在海量併發時也容易出現一些不可預期的穩定性問題。

　　2、FLV：FLV協議由Adobe公司主推，格式極其簡單，只是在大塊的視訊幀和音視訊頭部加入一些標記頭資訊，由於這種極致的簡潔，在延遲表現和大規模併發方面都很成熟。唯一的不足就是在手機瀏覽器上的支援非常有限，但是用作手機端APP直播協議卻異常合適。

　　3、HLS：蘋果原生：HTTP Live Streaming，遵循的是 HTTP 超文字傳輸協議，埠號8080，將視訊分成5-10秒的視訊小分片，然後用m3u8索引表進行管理，由於客戶端下載到的視訊都是5-10秒的完整資料，故視訊的流暢性很好，但也同樣引入了很大的延遲(HLS的一般延遲在10-30s左右)。

　　7、點播中常見的資料傳輸協議主要有哪些?

　　常見的點播協議：HLS，HTTP

　　8、何為Nginx?有什麼特點?

　　Nginx 是一個遵循 HTTP 協議的伺服器!記憶體佔用少，併發能力強! 還有等等的優點，可自行google

　　9、何為homebrew?你用它安裝過什麼?常用命令有哪些?

　　homebrew是一個 Mac系統下所獨有的套件管理器，我要做直播，需要 rtmp 和 nginx ，單獨安裝很複雜，只要在終端裡輸入簡單的安裝相應的套件命令即可完成安裝，複雜的過程都靠 homebrew 規避掉了!

　　我用它安裝過很多東西，比如nginx 搭建流媒體伺服器等。

　　常用命令：brew install 、brew uninstall、brew search、brew list、brew update、brew help 等~

　　10、FFmpeg是什麼?

　　FFmpeg是一套用來記錄和轉換數字音視訊，並能將其轉化為流的開源計算機程式。拉流和推流離不開 FFmpeg 的幫助!

　　11、RTMP、HLS協議各自的預設埠號是?

　　RTMP埠號：1935

　　HLS埠號 ：8080

　　12、m3u8構成是?直播中m3u8、ts如何實時更新?

　　是一個索引地址/播放列表，通過FFmpeg將本地的xxx.mp4進行切片處理，生成m3u8播放列表(索引檔案)和N多個 .ts檔案，並將其(m3u8、N個ts)放置在本地搭建好的webServer伺服器的指定目錄下，我就可以得到一個可以實時播放的網址，我們把這個m3u8地址複製到 VLC 上就可以實時觀看!

　　在 HLS 流下，本地視訊被分割成一個一個的小切片，一般10秒一個，這些個小切片被 m3u8管理，並且隨著終端的FFmpeg 向本地拉流的命令而實時更新，影片進度隨著拉流的進度而更新，播放過的片段不在本地儲存，自動刪除，直到該檔案播放完畢或停止，ts 切片會相應的被刪除，流停止，影片不會立即停止，影片播放會滯後於拉流一段時間，

　　13、簡述如何在Mac上搭建本地直播伺服器?

　　見我的文章：

　　http://blog.csdn.net/hejjunlin/article/details/54425531

　　PS: FFmpeg推流至Nginx：可以推兩種流：RTMP流，推流至rtmplive;HLS流，推流至hls;其中，HLS流表現較明顯，在nginx的臨時目錄下，直觀的可看到m3u8索引檔案和N多個.ts檔案。m3u8列表會實時更新，且會動態更改當前播放索引切片(.ts)。這種實時更新的機制，不會使得.ts檔案長時間存在於Nginx伺服器上，且當推流結束之後，該目錄下的內容會被全部清除，這樣無形中減緩了nginx伺服器的壓力。另外，也闡釋了HLS這種流媒體播放相較RTMP延時較高的原因。

　　14、說說你平時在播放過程中做的優化工作

　　預載入，弱網優化，播放出錯重試機制，運營商劫持引起的起播慢，mediaserver的cpu佔有率很高，引起播放卡頓。起播時，只保留播放程序，kill 其他程序 。

　　第一時間獲得部落格更新提醒，以及更多android，原始碼分析，最新開源專案推薦，更多有價值的思考，歡迎關注我的微信公眾號，掃一掃下方二維碼或者長按識別二維碼

　　大連包皮手術多少錢 http://yyk.39.net/hospital/f9a8f_knowledges.html

　　大連正規男科醫院 http://yyk.39.net/hospital/f9a8f_comments.html