I am looking for a possibility to convert a JPEG with 444 YCbCr to 422 YCbCr. According to the RFC 2435 for RTP Streaming the JPEG file must have the JPEG 422 YCbCr format cause 444 is agianst the standard.
You must down sample to do this, you could essentially just skip a component in each chroma plane to achieve this. (Lose data)
There is some example code here which gives you a jist on how the reduction is performed https://github.com/rkrajnc/jpegdec/blob/master/sw/matlab/jpeg/jpeg_downsample.m
Furthermore this will only work (with data loss) if the Hufffman DCT coefficients have been created with the same scale or close enough to what is expected in the RFC..
You could probably just leave everything the way it is for other JPEG's but what it really comes down to is ensuring the Huffman tables are compatible with the ones in the RFC, if they are not you will have to either:
1) Implement some type of use of TypeSpecific to indicate HuffmanTables are included, do not write them when creating the JFIF Headers and include them as-is directly after any ProfileHeaders.
2) Implement some type of use of TypeSpecific to indicate to use a known alternate Huffman table, on the receiving side instead of writing the normal Huffman Tables, write the custom one.
Option 1 will allow VLC to work as it will ignore the TypeSpecific field use the data in the Payload resulting in you including your alternate Huffman tables. This technique can also be adopted to allow other encoded jpeg's besides Baseline or Progressive or any markers which needs to be included but is not supported via the RFC standard. (For instance this method can also be adopted to include more than 2 quantization tables, the first 2 would be stored in the Profile Header when Quality >= 100 and the last one would be stored after any DRI Profile Header if applicable directly in the payload.
(Although I think you can currently check for more then 2 tables by performing division on the length of the table and observing the precision bit table when decoding, Length is a 16 bit field so Quant tables with a length of up to 65535 bytes is valid.)
I have recently added support for this in my library inter alia and filled errata for Rfc2435.
http://www.rfc-editor.org/errata_search.php?rfc=2435&rec_status=15&presentation=records
The resolution is to use the TypeSpecific field in the profile header which is not currently used to describe each Hi, Vi bit fields through that byte.
There can never be more then 5 components in a scan, 0 - 4.
The first component was already described in the Type field along with the DRI and quality.
The possible value permutations are 4,2,1,0.
0 need not be described as black and white is achieved with sending only a single table and 1:1 is already supported.
My change source can also be found in my library at https://net7mma.codeplex.com.