锐英源精品开源心得，禁止转载，违法必究。

以RTSP和RTP实现托管媒体聚合之序言

在我开始主要文章之前，我会说，.NET支持音频数据处理了，如果开发者想要执行与音频相关的各种任务，如解码、编码和代码转换，有信息和具有完整的实现的库来支持开发...当你开始处理视频时，这些都是完全混乱的 - 这是真正的陷阱领域 - 编码和解码都困难....这有多种原因，最大的神话是托管代码对于处理视频数据来说还不够快。

事实是，每个编解码器彼此截然不同，并且编解码器中使用的压缩/解压缩通常被某种类型的专利所掩盖。此不幸意味着有人必须为该编解码器中使用的代码支付特许权使用费。另一个问题是视频的解码通常是标准化的，但编码不是。这意味着只要最终结果符合解码流的规范，您就可以以任何方式进行编码。这给开发人员带来了很大的自由，但也为这些个人提供了许多方式对数据进行编码。然而，一些比其他人更有效率，结果在使用的时间量以及所产生的结果中是可变的。

有几个可以帮助的库，如VLC或FFMPEG，这两个库都使用LibAvCodec。然而，该库是用“ C ++ ” 编写的，并且有一些注意事项要考虑到库的许可证 - 更不用说它会引入外部依赖和平台调用到你的代码中。

简而言之，如果你需要一个快速的比喻，你可以把视频解码和编码类比到压缩和解压文件...当你解码你解压缩数据，当你编码你压缩数据。压缩和解压缩，只是Zip压缩与Rar压缩不一样，  MPEG4压缩也不是H264压缩。

音频编码/解码也是如此，例如“mp3”和“wav”格式。两者之间的巨大差异主要涉及音视频。音频数据远远少于视频数据的复杂度，这意味着要解析的字节远远不足，引起了一个单独的问题：音频 - 在数据中小的“毛刺”或错误将导致更大的解码问题 - 与视频里“毛刺”或错误来对比，对视频数据进行解码，这不会在播放过程中导致任何重要的伪影。

如果您对波形音频的格式感兴趣以及如何操作它，请参阅CodeProject 这篇文章，该文章有很多很好的例子。

如果您对音频和视频数据的相似度如何，在高级别上有所不同，请查看此演示文稿。

通常，解码视频以在计算机屏幕上显示的最大因素是从YUV到RGB的色彩空间转换，必须对每个像素执行的是所得到的视频，这意味着在Quarter Common Interlace Format或更简单的QCIF分辨率是176x220）这个计算和转换需要在解码时执行大约25,000次。（每个像素一次，127 * 220 = 29840），或者少一点，如果你使用几个技巧。

单一的图像远不如系列的图像或视频那样复杂，因为您有BMP，GIF，JPEG，PNG等为您做的工作。每个人都有自己的优缺点列表，以及每个都有一个地方和目的。

JPEG图像格式不再受这种知识产权的影响（不再）。此外，它不再是传输或甚至存储图片的最佳方式。尽管如此，由于在过去20年中广泛采用Jpeg文件，因此有很多资源可以解释如何使用Jpeg文件及其包含的数据。

在JPEG2000和许多其他候选中之间的MPEG可以成功地实现JPEG，因为它允许传输的数据更小，因此使用较少的带宽。这增加了压缩和最终查看图像所需的复杂度。不幸的是，如果要将压缩数据完全转换为像RGB这样的格式，则会导致更高的CPU利用率。它也被最新版本的专利所担保。

通常，转换为RGB是因为在大多数机顶盒或电视机中用于在计算机屏幕上显示图像的格式。情况并非如此，因此，信息转换为RGB并且简单地以该平台的本机格式呈现（例如YUV），这就是为什么这些设备的处理器远远不如现代甚至是旧电脑

一些图形处理单元（GPU）或甚至一些现代的中央处理单元（CPU）甚至可以通过使用已知的SIMD或并行排除的高级数学和处理器内在函数加速处理，其他可以直接使用YUV编码数据或者将多个内核放在高度视觉化的解码过程对这种数据起作用，在某些情况下，需要这种高级例程的特殊编解码器使用专门的硬件，您自己的计算机中的网络堆栈如何利用NIC处理器执行校验和验证和其他操作由操作系统允许，随后实现更好的性能。

这篇文章和库与编解码和转码技术没有太大关系，也不是围绕着音频或视频，所以让我们来看看这篇文章是关于哪些内容的。