视频格式基础
封装格式分为视频封装格式（容器格式）和视频编码格式（媒体格式）。我们平时提到的mp4，flv，avi等名称都是指视频封装格式。
这些文件其实类似一个包裹，它的后缀则是包裹的包装方式。这些包裹里面，包含了视频（只有图像），音频（只有声音），字幕等。当播放器在播放的时候，首先对这个包裹进行拆包（专业术语叫做分离/splitting）,把其中的视频、音频等拿出来，再进行播放。
既然它们只是一个包裹，就意味着这个后缀不能保证里面的东西是啥，也不能保证到底有多少东西。包裹里面的每一件物品，我们称之为轨道(track)，一般有这么些：
视频(Video): 一般来说肯定都有，但是也有例外，比如mka格式的外挂音轨，其实就是没视频的mkv。注意我们说到视频的时候，是不包括声音的。
音频(Audio)：一般来说也肯定有，甚至可以有多个音轨，但是有些情况是静音的，就没必要带了。
章节(Chapter): 蓝光原盘中自带的分段信息。如果文件带上了，那么你可以在播放器中看到带章节的效果：.potplayer右键画面，选项-播放-在进度条上显示书签/章节标记。
字幕(Subtitles)：有些时候文件自带字幕，并且字幕并非是直接整合于视频的硬字幕，那么就是一起被打包在封装容器中。
其他可能还有附件等，不一一列举。每个类型也不一定只有一条轨道，比如经常见到带多音轨的MKV。
每个轨道，都有自己的编码格式。比如大家常说的，视频是H.264，音频是AAC，这些就是每个轨道的格式。
视频的编码格式，常见的有H.264(可以细分为8bit/10bit)，H.265(当前也有8bit/10bit之分)，RealVideo(常见于早期rm/rmvb)，VC-1(微软主导的，常见于wmv)。基本上，H.264=AVC=AVC1, H.265=HEVC。
音频的格式，常见的有 FLAC/ALAC/TrueHD/DTS-HD MA这四种无损，和AAC/MP3/AC3/DTS(Core)这四种有损。
常见视频编码格式：
AVC(H264)是目前主流的视频压缩编码，不论电脑软件、手机、硬盘播放器、高清盒子，都支持对H264的解码。如果视频采用这种编码，目前来说，视频质量有保证，兼容性非常好。
HEVC(H265)是最新的视频压缩编码，编码效率比H264有较大提升。可以说，同等文件大小，HEVC的视频质量最好；同等视频质量，H265的体积最小。但是，因为编码比较新，有些播放软件、高清播放机、高清盒子、智能电视、智能手机是不支持这种编码的。
常见的几种封装格式：
AVI：Audio Video Interactive，即音频视频交错格式，是微软公司于1992年11月推出、作为其Windows视频软件一部分的一种多媒体容器格式，V2.0于1996年发布。只能有一个视频轨道和一个音频轨道（有非标准插件可加入最多两个音频轨道），还可以有一些附加轨道，如文字等，不提供任何控制功能。
因为推出时间早，而存活时间长，所以很多早期视频都是以avi格式发布的，典型就是各种盗版av资源，压缩比不高，所以虽然画质很差但体积依然很大。
WMV：Windows Media Video，是微软开发的一系列视频编解码和其相关的视频编码格式的统称，在2003年，微软基于其WMV 9格式提出了视频压缩规程的草案，将其提交SMPTE学会进行标准化。在2006年3月学会官方通过了SMPTE 421M标准, 即更熟知的VC-1标准，使WMV 9格式成为一种开放的标准。VC-1连同H.262/MPEG-2 Part 2和H.264/MPEG-4 AVC，成为蓝光光碟的三种视频格式之一。ASF（Advanced Systems Format）是其封装格式。ASF封装的WMV档具有“数位版权保护”功能。
在网络资源中占比相对较少，特点是具有加密功能，早期经常被捆绑各种广告与木马病毒。
RM，RMVB：RealMedia Variable Bitrate，RealNetworks公司开发的RealMedia多媒体数字容器格式的可变比特率（VBR）扩展版本。相对于更常见的按固定比特率（CBR）编码的流媒体RealMedia容器，RMVB典型应用于保存在本地的多媒体内容。VB指的是Variable Bitrate，动态码率或可变比特率，是RealNetworks公司的编码格式的9.0版本。RealMedia使用的压缩方法类似MPEG-4 Part 10编码，比如x264。
rm格式是当年的主打，因为压缩率高，画面可以接受，所以在早期资源组中很受欢迎。
但是，问题在于：
a)realmedia闭源。这造成很多播放器无法播放rm，因为需要交授权费。这个问题在机顶盒等嵌入式设备上尤为突出。
b）在带宽不那么紧张的今天，rm无法提供更好的画质，以适应播放条件更加宽松的高清需求。具体有很多对比，SOSG做过一个测试，详细的阐述了这个问题，此次不再赘言。结论是：在同样码率（可以理解为文件大小）的情况下，H.264可以提供更好的画质。
c）看不到realmedia改进的希望。real公司一直坚持闭源，无视环境变化。没有拿出任何令人兴奋的改进。
d）rm对在线视频不甚友好。
所以逐渐退出历史舞台，被更强大的mp4所替代。
FLV：FLASH VIDEO，FLV流媒体格式是随着Flash MX的推出发展而来的视频格式。由于它形成的文件极小、加载速度极快，被众多新一代视频分享网站所采用，是增长最快、最为广泛的视频传播格式。是在sorenson公司的压缩算法的基础上开发出来的。
使用h.264编码的flv即f4v，flv使用h.263编码。
早期的视频站，包括youku土豆新浪等，线上视频都是使用flv格式。
战渣浪，二压，后黑与6分钟魔咒
在AB站刚兴起的那段时间，AB站本身是不提供直接上传功能的，都是先在其他平台，比如youku土豆新浪视频等，上传完成后，再把视频地址填过来，完成搬运。
所以其实当时也没有up主这个概念，大部分都是单纯的搬运工。
而随着时间发展，部分搬运工开始对画质产生了更高的要求，于是就开始对各平台的上传策略进行了研究。
youku土豆有水印，且在某个时间段内禁止了外链，新浪视频有上传服务，没有水印，所以在很长一段时间里，新浪的视频源是一众搬运工的首选。
二压
各视频平台会对非flv格式的或者码率大于某个特定值的视频进行一视同仁的二次压制。新浪当时的标准猜测是500-1000kbps。
后黑
在视频中插入全黑的画面，让视频的码率被识别为更低，从而让网站不会对视频进行二压。
6分钟魔咒
新浪对上传的视频会划分成几个部分，差不多每6分钟一个。播放器会获取播放文件表，这个文件里就包含了实际对应的视频文件。分成的每一部分都放在不同域名的服务器上，这样一来，每缓冲6分钟就会重新连接另外一个服务器。如果服务器的反应较慢，就很可能出现黑屏诅咒，这种情况下刷新几次页面、清清缓存就可能会好。最糟糕的情况就是服务器挂掉了，这种情况下再怎么刷新也没用。
MKV：Matroska，由俄罗斯的程序员开发的开源的开放标准的自由的容器和文件格式。能够在一个文件中容纳无限数量的视频、音频、图片或字幕轨道。所以其不是一种压缩格式，而是Matroska定义的一种多媒体容器文件。其目标是作为一种统一格式保存常见的电影、电视节目等多媒体内容。可将多种不同编码的视频及16条以上不同格式的音频和不同语言的字幕流封装到一个Matroska 媒体文件当中。最大的特点就是能容纳多种不同类型编码的视频、音频及字幕流。
MPEG-4：Moving Picture Experts Group 4，由国际标准化组织（ISO）和国际电工委员会（IEC）下属的“动态图像专家组”（Moving Picture Experts Group，即MPEG）制定，第一版在1998年10月通过，第二版在1999年12月通过。MPEG-4格式的主要用途在于网上流、光盘、语音发送（视频电话），以及电视广播。
除此之外还有MOV，DivX/xvid，OGG，3GP，MOD等。
MKV支持封装FLAC作为音频，MP4则不支持。但是MP4也可以封装无损音轨(比如说ALAC，虽然普遍认为ALAC的效率不如FLAC优秀)
MKV支持封装ASS/SSA格式的字幕，MP4则不支持。一般字幕组制作的字幕是ASS格式，所以内封字幕多见于MKV格式
MP4作为工业标准，在视频编辑软件和播放设备上的兼容性一般好于MKV。这也是vcb-s那些为移动设备优化的视频基本上选择MP4封装的原因。
除此之外，这两个格式很大程度上可以互相代替。比如它们都支持封装AVC和HEVC，包括8bit/10bit的精度。所以MP4画质不如MKV好，这种论断是非常无知的——它们完全可以封装一样的视频。
为什么会有这样的分歧，就是历史原因了。MKV是民间研发，为了代替古老的AVI，从而更好地支持H264，它开发和修改的灵活度使得它可以兼容flac/ass这类非工业标准的格式；而MP4则是出生豪门，作为工业标准，替代更古老的MPG，作为新一代视频/音频封装服务的。
字幕
外挂,内嵌与内封
Title,Subtitle,Caption
视频数据的基础参数：分辨率，帧率和码率。
视频是由连续的图像构成的。每一张图像，我们称为一帧(frame)。图像则是由像素(pixel)构成的。一张图像有多少像素，称为这个图像的分辨率。比如说1920×1080的图像，说明它是由横纵1920×1080个像素点构成。视频的分辨率就是每一帧图像的分辨率。
一个视频，每一秒由多少图像构成，称为这个视频的帧率(frame-rate)。常见的帧率有24000/1001=23.976, 30000/1001=29.970, 60000/1001=59.940, 25.000, 50.000等等。这个数字是一秒钟内闪过的图像的数量。比如23.976，就是1001秒内，有24000张图像。视频的帧率是可以是恒定的(cfr, Const Frame-Rate)，也可以是变化的(vfr, Variable Frame-Rate)
码率的定义是视频文件体积除以时间。单位一般是Kbps(Kbit/s)或者Mbps(Mbit/s)。注意1B(Byte)=8b(bit)。所以一个24分钟，900MB的视频：
体积：900MB = 900MByte = 7200Mbit
时间：24min = 1440s
码率：7200/1440 = 5000 Kbps = 5Mbps
当视频文件的时间基本相同的时候（比如现在一集番大概是24分钟），码率和体积基本上是等价的，都是用来描述视频大小的参数。长度分辨率都相同的文件，体积不同，实际上就是码率不同。
码率也可以解读为单位时间内，用来记录视频的数据总量。码率越高的视频，意味着用来记录视频的数据量越多，潜在的解读就是视频可以拥有更好的质量。
音频数据就没有帧的概念了，就是一包一包的音频数据。下面计算一下 pcm 音频流的码率，采样率值×采样大小值×声道数 bps。一个采样率为 44.1khz，采样大小为 16bit，双声道的pcm编码的wav文件，它的数据速率则为 44.1k×16×2 = 1411.2 kbps。我们常说 128k 的mp3，对应的 wav 的参数，就是这个 1411.2 kbps，这个参数也被称为数据带宽，它和 adsl 中的带宽是一个概念。将码率除以 8，就可以得到这个 wav 的数据速率，即 176.4kb/s。这表示存储一秒钟采样率为 44.1khz，采样大小为 16bit，双声道的 pcm 编码的音频信号，需要 176.4kb 的空间，1分钟则约为 10.34m，这对大部分用户是不可接受的，尤其是喜欢在电脑上听音乐的朋友，要降低磁盘占用，只有2种方法，降低采样指标或者压缩。降低指标是不可取的，因此就有了各种压缩方案。
[略]图像的表示方法：RGB模型 vs YUV模型、色深、，色度半采样、动态、清晰度与画质简述
流媒体
所谓流媒体是指采用流式传输的方式在 Internet 播放的媒体格式。
流媒体又叫流式媒体，它是指商家用一个视频传送服务器把节目当成数据包发出，传送到网络上。
用户通过解压设备对这些数据进行解压后，节目就会像发送前那样显示出来。
流媒体以流的方式在网络中传输音频、视频和多媒体文件的形式。
由服务器向用户计算机连续、实时传送。在采用流式传输方式的系统中，用户不必像非流式播放那样等到整个文件全部下载完毕后才能看到当中的内容，而是只需要经过几秒钟或几十秒的启动延时即可在用户计算机上利用相应的播放器对压缩的视频或音频等流式媒体文件进行播放，剩余的部分将继续进行下载，直至播放完毕。
常用的流媒体协议主要有HTTP渐进下载和基于RTSP/RTP的实时流媒体协议两类。在流式传输的实现方案中，一般采用HTTP/TCP来传输控制信息，而用RTP/UDP来传输实时多媒体数据。
1 实时传输协议RTP与RTCP
RTP(Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输协议。
不像http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。
RTP协议是建立在UDP协议上的,本身并没有提供按时发送机制或其他服务质量（QoS）保证，它依赖于底层服务去实现这一过程。RTP并不保证传送或防止无序传送，也不确定底层网络的可靠性。
实时传输控制协议（Real-time Transport Control Protocol,RTCP）是实时传输协议（RTP）的一个姐妹协议。
RTCP为RTP媒体流提供信道外控制。
RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量提供反馈。
2 实时流协议RTSP
实时流媒体会话协议,SDP(会话描述协议)，RTP(实时传输协议)。
RTSP与RTP最大的区别在于：RTSP是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。当然RTSP可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。它是一种类似于HTTP协议的网络应用协议。
3 资源预定协议RSVP
RSVP即资源预订协议，使用RSVP预留一部分网络资源（即带宽），能在一定程度上为流媒体的传输提供QoS。RSVP、RTSP与RTP协议工作在不同的层次，如下图所示。
4 实时消息传输协议RTMP（Real Time Messaging Protocol）
（1）RTMP协议是采用实时的流式传输，所以不会缓存文件到客户端，这种特性说明用户想下载RTMP协议下的视频是比较难的；
（2）视频流可以随便拖动，既可以从任意时间点向服务器发送请求进行播放，并不需要视频有关键帧。相比而言，HTTP协议下视频需要有关键帧才可以随意拖动。
（3）RTMP协议支持点播/回放（通俗点将就是支持把flv,f4v,mp4文件放在RTMP服务器，客户端可以直接播放），直播（边录制视频边播放）。
5 微软媒体服务器协议MMS（Microsoft Media Server Protocol）
6 HLS
HTTP Live Streaming(HLS)是苹果公司实现的基于HTTP的流媒体传输协议，可实现流媒体的直播和点播，主要应用于iOS系统。HLS点播是分段HTTP点播，不同在于它的分段非常小。要实现HLS点播，重点在于对媒体文件分段，目前有不少开源工具可以使用。
相对于常见的流媒体直播协议，HLS直播最大的不同在于，直播客户端获取到的并不是一个完整的数据流，HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。
在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8)playlist文件，用于寻找可用的媒体流。
视频的编码格式为H264,音频编码格式为MP3、AAC或者AC-3。
除了TS视频文件本身，还定义了用来控制播放的m3u8文件（文本文件）。
为什么苹果要提出HLS这个协议，其实他的主要是为了解决RTMP协议存在的一些问题。比如RTMP协议不使用标准的HTTP接口传输数据，所以在一些特殊的网络环境下可能被防火墙屏蔽掉。但是HLS由于使用的HTTP协议传输数据，不会遇到被防火墙屏蔽的情况（该不会有防火墙连80接口都不放过吧）。
另外于负载，RTMP是一种有状态协议，很难对视频服务器进行平滑扩展，因为需要为每一个播放视频流的客户端维护状态。而HLS基于无状态协议（HTTP），客户端只是按照顺序使用下载存储在服务器的普通TS文件，做负责均衡如同普通的HTTP文件服务器的负载均衡一样简单。
另外HLS协议本身实现了码率自适应，不同带宽的设备可以自动切换到最适合自己码率的视频播放。其实HLS最大的优势就是他的亲爹是苹果。苹果在自家的IOS设备上只提供对HLS的原生支持，并且放弃了flash。Android也迫于平果的“淫威”原生支持了HLS。这样一来flv，rtmp这些Adobe的视频方案要想在移动设备上播放需要额外下点功夫。当然flash对移动设备造成很大的性能压力确实也是自身的问题。
但HLS也有一些无法跨越的坑，比如采用HLS协议直播的视频延迟时间无法下到10秒以下，而RTMP协议的延迟最低可以到3、4秒左右。所以说对直播延迟比较敏感的服务请慎用HLS。
低延迟需要 基于rudp（可靠用户数据报协议）实现的WebRTC协议，进行rts推流，淘宝的直播使用了该技术。
评论已关闭