在 Theora 1.0 发布不到一年后，Xiph 的优秀团队发布了 Theora 1.1。1.1 版本是 Theora 编码器和解码器 的纯软件版本。它没有对 Theora 格式进行任何更改。现有的 Theora 视频应该能够继续使用新的解码器播放，并且新的 Theora 编码器生成的比特流可以在能够播放 Theora 内容的现有播放器中工作。

1.1 版本主要改进了 Theora 编码器。这篇文章将尝试向大家提供关于这些更改的高级概述，以及它们对 Web 开发人员和考虑部署 Theora 来支持 HTML5 视频的人员意味着什么。Theora 对于 Web 开发人员来说是一项重要的技术——它是目前唯一符合 W3C 专利政策 的竞争性编解码器。

以下列出了此版本中一些重要的更改。我们将详细介绍每个项目。

• Theora 1.1 提高了视频质量。
• 实时流媒体的码率控制现在运行良好。
• 编码器添加了双通道模式，可以创建具有非常可预测带宽需求的码率控制视频。
• 编码过程中的 CPU 使用率更加稳定。
• 解码器性能得到了提升。

Theora 1.1 提高了视频质量。

Theora 1.0 编码器的一个问题是它生成的视频看起来比较模糊。通过 Xiph 开发人员之一 Monty 提供的两张图片可以清楚地看到 1.1 的改进。在新的标签页中打开每个图片并进行切换。你可以看到明显的区别。

这在文本边缘也表现得很明显。以下是我们 Firefox 3.5 促销视频 中的一个例子。第一个使用的是 1.0 编码器 (9.0MB)，第二个使用的是 1.1 编码器 (8.2MB)。你会注意到，不仅边缘更加清晰，而且文本边缘周围的噪点也少了很多。同样，如果你在标签页中打开它们并进行切换，你就可以看到区别。

请注意，原始的 视频 接近 17MB。这主要是为了使文本清晰。通过这些更改，我们可能可以使用更低带宽版本的视频，可能小到 9.9MB。这是一个很大的差别。

请注意，我们讨论的是在相同视频比特率下的质量改进。这意味着我们要么能够在相同的文件大小下生成更高质量的视频，要么能够减小文件大小并保持相同的质量——无论哪种方式，这都是一个巨大的胜利。

实时流媒体的码率控制现在运行良好。

在描述此更改之前，必须先说明一些重要内容。这就是使用可变比特率 (VBR) 和恒定比特率 (CBR) 编码的视频之间的区别。

在可变比特率编码中，表示视频中两帧之间差异所需的数据量可以增长。当从一个运动不多的场景切换到一个运动剧烈的场景时，这种情况最常发生。你可能会很容易地从需要 40Kb/秒增加到 400Kb/秒，因为整个背景都在移动。

在恒定比特率编码中，用于表示从一帧到下一帧变化的数据量被固定在某个最大值。如果你有一个较低的最大值，并且有一组帧需要大量比特来表示从一个到下一个的变化，则需要牺牲一些东西才能保持在该最大值以内。通常会牺牲一些视频质量，或者编码器会开始丢帧以保持在水印之下。

这导致了一个非常简单的规则：如果你想要获得尽可能高的视频质量，则应该使用可变比特率编码。这意味着，当你对视频进行编码时，应该使用质量设置（0-99、低/中/高、1-10），而不是选择比特率（60Kb/秒、200Kb/秒）。对于 Web 上的大多数用例来说，VBR 编码的视频实际上运行良好，因为用户可以在当前位置之前缓存相当多的视频，因此这些数据突发不会影响用户体验。

但是，在某些情况下，使用恒定比特率非常重要。这些包括

1. 通过 HTTP 进行的具有大量客户端的低延迟实时流媒体。
2. 流式传输大型文件，其中不希望使用大型预读缓冲区。
3. 数据大量突发导致 CPU 处理大量突发的情况。

对于通过 HTTP 进行的低延迟实时流媒体，了解在需要处理突然的数据突发时会发生什么非常重要。HTTP 运行在 TCP 之上。在 TCP 中，连接需要一段时间才能增加其带宽。（“一段时间”的意思是“不是那么长”，但它足够长，会影响我们在此用例中想要的低延迟连接。这就是为什么许多低延迟应用程序不使用 TCP 的原因。但我们正在讨论通过 HTTP 传输视频。）如果你有大量数据突发并且 TCP 窗口需要很长时间才能打开，你就会开始在服务器上构建一个大型发送缓冲区。（并且请记住，在此用例中，你有很多客户端连接！）这需要大量内存来保存每个客户端的发送缓冲区。然后发生的情况是，服务器会开始大量关闭连接，因为它需要节省内存或者因为它认为客户端已变得无法访问。更糟糕的是，即使连接扩展然后缩小，它也会重新稳定在低速率，并且必须重复此过程。用户体验是视频流停止并重新启动或在服务器挂起时完全停止工作。解决方案？使用恒定速率，它不需要 TCP 窗口突然打开，也不需要为每个客户端提供大型发送缓冲区。

对于流式传输大型文件的用例，客户端缓存大量数据可能不合理。你可能也正在向大量客户端提供大量数据，并且可能也希望避免大型发送缓冲区问题，只是出于不同的原因。

对于你在 CPU 受限环境中的最后一个用例，可变比特率视频的突发特性意味着通常需要大量 CPU 突发来处理这些突发。虽然 CPU 的突发速度比 TCP 快，但你可能正在与受限处理器（例如移动设备）通信，或者你可能正在提供接近高清大小的内容的文件，而 CPU 通常难以解码这些内容。

无论如何，恒定比特率编码都有许多用例。回到 Theora 1.1 中改进的内容的问题。

在 Theora 1.0 中，码率控制编码模式非常糟糕。这导致了两件事

1. 尝试进行实时流媒体的人遇到了问题。
2. 使用码率控制设置将 Theora 的整体质量与其他编码器的质量进行比较的人，看到的 Theora 结果比该格式实际代表的结果更差。

第一个问题很清楚——它坏了，应该修复。并且已经修复了。新的编码器在保持比特率方面做得很好，可以动态更改质量，丢弃帧，甚至包括“软目标”模式，以便比特率可以稍微波动以保持质量，同时偶尔会违反带宽规则。

编码器还具有一项很棒的新功能，人们会发现它非常有用。现在可以为视频编码指定最大速率上限，同时还可以指定最低质量下限。这意味着编码器将尝试在速率约束内保持非常清晰的视频帧。这意味着它会积极丢弃帧，而不是创建模糊或低质量的帧增量。虽然这听起来像是权衡取舍，但实际上非常有用。如果你正在展示演示文稿的实时视频，你通常希望幻灯片的视频清晰，并且较低的帧更新率是可以接受的。

Theora 1.0 中糟糕的码率控制导致的第二个问题是营销问题。人们通常会使用固定比特率模式而不是质量模式进行编码，并将结果视为格式的反映，而不是编码器的问题。我们希望人们在使用新的编码器时能够获得更好的结果。

编码器添加了双通道模式，可以创建具有非常可预测带宽需求的码率控制视频。

除了在 1.1 中修复单通道码率控制编码器之外，还添加了一个双通道编码选项。这意味着，如果你正在转码文件（而不是进行实时流媒体），则可以根据需要在文件中创建非常一致的比特率。这是因为编码器可以提前查看流以有效地分配比特。 来自 Xiph 的 Monty 制作了一个图表，显示了一个文件在使用单通道和双通道时的比特率示例。

上图：使用默认双通道比特率管理与单通道（使用 –soft-target）在 [黑客帝国电影片段] 处以 300kbps 编码时的量化器选择（大致对应于编码质量）图表。两种编码都产生了相同的比特率。单通道编码的质量变化很大，因为编码器无法提前计划。

编码过程中的 CPU 使用率更加稳定。

进行实时流媒体的人通常会在高运动事件期间看到 CPU 使用率出现巨大峰值。这个问题已经得到修复，现在在单通道码率受限编码期间，CPU 使用率更加稳定，从而使实时流式传输视频变得更加容易。

解码器性能得到了提升。

最后但并非最不重要的是，在 1.1 版本中，解码器速度更快。速度提升多少在很大程度上取决于片段，但人们报告说，新的编码器比 libtheora 的 1.0 版本快 1.5-2 倍。

即将登陆您附近的某个产品。

此版本是库版本。它本身不是产品，而是其他产品包含的内容。因此，在接下来的几天和几周内，我们将看到其他产品采用并开始将其用作其版本的一部分。

尽情享受吧！