如何将JPEG 444 YCbCr转换为422 YCbCr

Question

我正在寻找一种可能的转换与444 YCbCr到422 YCbCr的JPEG。根据RFC 2435，对于RTP流，该JPEG文件必须具有JPEG 422 YCbCr格式，因为444是标准的。

Answer 1

--你必须降低样本才能做到这一点，你基本上可以跳过每个色度平面中的一个分量来实现这一点。(丢失数据)

这里有一些示例代码，它为您提供了如何执行downsample.m的简化操作的jist。

此外，只有在赫夫曼DCT系数以相同的比例创建或与RFC的期望足够接近的情况下，这才能起作用(数据丢失)。

你也许可以把所有的东西都留给其他的，但是真正的问题是确保Huffman表和RFC中的表兼容，如果它们不兼容的话，你也必须这样做：。

1)实现了对TypeSpecific的某种类型的使用，以指示包含了HuffmanTables，在创建JFIF头时不要写入它们，并将它们作为-直接包含在任何ProfileHeaders之后。

2)实现了对TypeSpecific的某种类型的使用，以指示在接收端使用已知的备用Huffman表，而不是编写普通的Huffman表，而是编写自定义的表。

选项1将允许VLC工作，因为它将忽略TypeSpecific字段，使用Payload中的数据，从而导致您包括您的备用Huffman表。这一技术也可以用于允许其他编码的jpeg，除了基线或渐进，或任何标记需要包括，但不支持通过RFC标准。(例如，还可以采用这种方法来包括多个量化表，当质量>= 100时，前2将存储在配置文件标头中，最后一表将存储在任何直接适用于有效载荷的DRI配置文件报头之后。

(虽然我认为目前可以通过对表的长度进行除法并在解码时观察精确位表来检查两个以上的表，但是长度是一个16位字段，因此长度高达65535字节的Quant表是有效的。)

最近在我的库中添加了对此的支持，并为Rfc2435.填写了勘误表。

status=15&presentation=records

解析是使用概要文件头中的TypeSpecific字段，该字段目前不用于通过该字节描述每个Hi、Vi位字段。

一次扫描中不可能有超过5个组件，0- 4。

第一个组件已经与DRI和quality一起在Type字段中进行了描述。

可能的值排列为4,2,1,0。

不需要将0描述为只发送一个表就可以实现黑白，并且已经支持1:1。

我的变更源也可以在https://net7mma.codeplex.com的库中找到。