我正在寻找将444 YCbCr的JPEG转换为422 YCbCr的可能性。 根据用于RTP流的RFC 2435，JPEG文件必须具有JPEG 422 YCbCr格式，因为444是最标准的。
答案 0 :(得分：0)
您必须向下采样才能执行此操作，您基本上可以跳过每个色度平面中的一个组件来实现此目的。 （丢失数据）
这里有一些示例代码，为您提供有关如何执行缩减的问题https://github.com/rkrajnc/jpegdec/blob/master/sw/matlab/jpeg/jpeg_downsample.m
此外，只有当Hufffman DCT系数以相同的比例创建或足够接近RFC中的预期时，这才会起作用（数据丢失）。
您可能只是将所有内容保留为其他JPEG格式的内容，但它真正归结为确保Huffman表与RFC中的表兼容，如果它们是不是你必须：
1） 实现TypeSpecific的某种类型的使用以指示包含HuffmanTables，在创建JFIF标头时不要写它们并在任何ProfileHeader之后直接包含它们。
2） 实现某种类型的TypeSpecific使用，以指示使用已知的备用Huffman表，在接收端而不是写正常的Huffman表，编写自定义的。 / em>的
选项1将允许VLC工作，因为它将忽略TypeSpecific字段使用Payload中的数据，从而导致您包括备用Huffman表。除了Baseline或Progressive之外，还可以采用这种技术来允许其他编码的jpeg，或者需要包含但不通过RFC标准支持的任何标记。 （例如，也可以采用此方法包含2个以上的量化表，当质量＆gt; = 100时，前2个将存储在配置文件头中，最后一个将存储在任何DRI配置文件头之后，如果直接适用于有效载荷。
（虽然我认为你可以通过对表的长度进行除法并在解码时观察精度位表来检查超过2个表，但是长度是16位字段，所以Quant表的长度最多为65535 bytes是有效的。）
我最近在我的图书馆中添加了对此的支持，并填写了Rfc2435的勘误表。
http://www.rfc-editor.org/errata_search.php?rfc=2435&rec_status=15&presentation=records
分辨率是使用配置文件头中的TypeSpecific字段，该字段当前不用于描述该字节中的每个Hi，Vi位字段。
扫描中永远不会有超过5个组件，0 - 4。
第一个组件已在“类型”字段中与DRI和质量一起描述。
可能的值排列是4,2,1,0。
0不需要描述为只发送一个表就可以实现黑白，并且已经支持1：1。
我的更改源也可以在https://net7mma.codeplex.com的我的库中找到。