我一直在研究多媒体格式（尽管最近有人告诉我不要使用“格式”这个词，因为它含义模糊。）
我了解到视频文件由原始比特流根据某种标准进行编码，例如H.264，然后该比特流被打包成容器例如.mp4。
IE原始比特流（编码为标准协议）+ 容器=我的视频文件
我是从另一篇超级用户文章中了解到这一点的：什么是编解码器（例如 DivX？），它与文件格式（例如 MPG）有何不同？
在这篇文章中，还说了这样一句话：
到目前为止，我们只解释了原始“比特流”，它基本上就是真正的原始视频数据。您实际上可以使用这种原始比特流继续观看视频。但在大多数情况下，这还不够或不切实际。
因此，您需要将视频包装在容器中。原因如下：
-也许您想要一些与视频一起的音频。
-也许您想跳到视频中的某个部分（例如，“转到 1:32:20.12”）。
-音频和视频都应该完美同步。
-视频可能需要通过可靠的网络传输并先分成数据包。
-视频甚至可能通过有损网络（如 3G）发送并先分成数据包。
我真的不明白为什么原始比特流不能如何使用，以及如何容器可以允许所有这些事情。他说他们能但他没有解释如何，这就是我要说的。
这可能是因为我这辈子从来没有处理过原始比特流。我总是点击 .mp4 容器文件，它就正常工作了。
有人可以解释一下容器的魔力以及它们如何增强原始比特流吗？
答案1
容器将元数据添加到一个或多个“原始比特流”中。我们可以将后者想象成传统的胶卷：一系列图像，仅此而已。容器将充当存储胶卷的盒子：它添加标题、索引位置（场景 2 从 03:45 开始）、总长度等。
没有容器的纯视频可以工作；显然，可以在没有索引的情况下计算持续时间，但这很快就变得不切实际——需要解码整个视频才能获得其总长度，因为存储一秒钟影片所需的数据量不一定是恒定的（某些编解码器甚至允许可变帧速率）。要快进十秒，需要预先解码十秒的视频；要快退十秒，则需要从头开始重新解码，或者需要保留已看过内容的运行索引。既不美观也不高效。
因此，在流媒体的情况下，容器简化了查找或获取总长度等操作；无需预先下载超出实际需要的数据。观看会话可以从一半开始，而无需下载然后解码前半部分。
同样的限制也适用于纯音频。
因此，现在要同步音频和视频，需要两个不同的数据流。在读取两个文件之间来回切换（即使每个文件都有不同的容器）会导致无用的性能损失，并且在加载的计算机上，可能意味着视频已准备好播放，但音频仍在磁盘上等待。容器将数据分块成可管理的短簇（最多几秒钟），其中视频和音频在存储介质（或网络上）上彼此相邻。如果传输发生在有损网络上，并且数据包丢失，播放器可以轻松恢复播放下一个簇，而无需处理数据丢失估计以确保视频和音频保持同步。
因此，容器主要存储可以从“原始比特流”中轻松收集的冗余信息，但这种添加使得许多操作更加高效并增加了可靠性。