晚上在找和研究關於SDL2.0關於處理流媒體的文章，搜索了一段時間看到都是一些支離破碎的信息，但是關於一些處理靜態圖片或文字的一些code sample是比較詳細的。對此結果覺得很不太滿意，就繼續在網上深挖了一陣。在搜索過程中，偶然的突然點解讓自己明白過來，也就最終停止了搜索。
從原理上來說，視頻方面只是利用一秒播更多的靜態畫面，達到流暢畫面的目的，讓人產生視頻的感覺。因爲人眼只要接受超過一秒24幅圖片，就會認爲是連續的畫面。基於這樣的認識，那麼只需要提供足夠多的不同圖片，在一定間隔時間內不斷地畫圖片，就可以玩出視頻播放。
特定的來說，關於流媒體的SDL2.0的處理，也就不太需要code sample了。因爲流媒體準備了足夠多的圖片來源，那麼將流媒體經過ffmpeg等編解碼庫處理爲SDL可以接受的輸入(YUV或這RGB等)，即可以完成流媒體的播放，就這麼簡單！
在做視頻畫中畫的時間，其實類似靜態圖片的前景和後景，準備好數據後，兩次填充目標區域數據， 一次顯示即可。所有都是基於靜態展開的動態過程。但如果考慮畫中畫可以拖動，則需要另外考慮實現:)
說起來話多，這段惡補一些關於圖像方面的知識，就一道總結總結。例如在視頻中幀率、分辨率、碼率等是關鍵指標。幀率影響畫面流程的程度，分辨率影響圖像的尺寸和細節反映程度，而碼率則很大程度上受限於前兩者，碼率可以簡單理解爲單位時間內bits數，在網絡上傳輸就體現爲帶寬。在碼率關鍵參數上面視頻的編解碼庫可以在壓縮程度上讓碼率有一些上下的活動空間，但相對來說前兩者影響更大些。如果在帶寬不是很好的情況下，可以降低幀率或分辨率來達到畫面流暢，這樣可以來的更直接。
在這段學習中流媒體格式H.264中有一個概念困擾了我很長時間，就是H.264規範界定了序列、圖像的參數集和序列、圖像的數據在邏輯上是兩個不同的通道。通過這個區分可以一方面可以達到比較高效的編解碼效率，另一方面也可以保證解碼所必須的參數集信息可以通過更可靠的信道進行傳輸。但困惑我的問題是，我所見到的一個視頻項目中沒有看到一個明確的參數集的傳遞過程，但是卻不影響播放視頻過程？！豈不怪哉！。愛好理性的我，一直在追求這個問題的答案，後來才知道，流媒體數據通過RTP鏈路NAL封裝，參數集也被封裝在NAL中，而且參數集具有自己獨立的NAL TYPE值。參數集具體又可分爲序列參數集(SPS)、圖像參數集（PPS）。在項目實際中實際上是通過一條RTP鏈路傳遞過來，而對於參數集的可靠性則可通過軟實現予以保證，例如重傳等。
