4:2:0 Type 2 to 4:2:2 normal chroma placement via FFMpeg

[FranceBB]

Alright guys, the question is the following:

If I have a 4:2:0 Type 2 source (so top left, 0,0 chroma location) and I use:

FFMpeg.exe -i "test.m2ts" -pix_fmt yuv422p

And then save the video, will FFMpeg:

A) Convert from top left to the old MPEG-2 chroma location, hence creating a perfectly fine yv16?

B) Create a non standard yv16 with the chroma sitting in top left, 0,0, which will be read wrongly by any decoder?

C) Upscale the chroma assuming the old MPEG-2 location instead of top left, hence screwing everything up?



I know that you can use:

-vf 'scale=out_color_matrix=bt709:out_h_chr_pos=0:out_v_chr_pos=128'

To go from type 2 to the old MPEG-2 one and also:

-vf scale=out_color_matrix=bt709:out_h_chr_pos=0:out_v_chr_pos=0

To do the opposite and go from the old MPEG-2 to the new Type 2, but the question still remains: what happens if someone just specifies the pix_fmt?

[wswartzendruber]

I've always had to pass resampling in as a video filter. -pix_fmt for me has only ever served to configure raw input properties.

[Balling]

The answer is C for full and limited at least for hevc and for raw muxer. FFmpeg does not see input correctly, so you must force it with

ffmpeg.exe -i cosmos.mkv -vf 'scale=in_h_chr_pos=0:in_v_chr_pos=128' -pix_fmt rgb24 qnfvarejwnfe3.rgb for left
ffmpeg.exe -i cosmos.mkv -vf 'scale=in_h_chr_pos=0:in_v_chr_pos=0' -pix_fmt rgb24 qnfvarejwnfe3.rgb for top-left


For a very long time zimg wrapper in ffmpeg was broken in chroma sample location. https://github.com/FFmpeg/FFmpeg/commit/27c0dd55609daf440a7744e96ac20c119bbeb80f

>-pix_fmt for me has only ever served to configure raw input properties.

Very funny. But yes. It is ONLY for .yuv .rgb files. Its use for anything else was deprecated, -pixel_format is used there. (The last one does not work for raw, confusing, I know.)