图像显示和流媒体播放点解

     晚上在找和研究关于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链路传递过来，而对于参数集的可靠性则可通过软实现予以保证，例如重传等。