MediaInfo and Avisynth disagree on color space after encode, which is correct?

[Fullmetal Encoder]

I am having a problem determining what the real color space is of my video. I have a fully YUV 4:2:0 chain up until the point at which I encode my video with UT Codec (in 4:2:0 mode, ULY0). When I examine the output file with MediaInfo it tells me the video is YUV 4:2:2. When I use Info() in Avisynth it tells me the color space is YUV 4:2:0.

I'm doing the best I can to avoid any color conversions. At this point, I'm not sure if MediaInfo is misreporting the color space, or if UT Codec is damaging the file somehow, or is Avisynth is misreporting the information.

I've tried posting in the UT Codec thread but I haven't been able to get a response from anyone.

Any help would be much appreciated.

[list]

I am having a problem determining what the real color space is of my video. I have a fully YUV 4:2:0 chain up until the point at which I encode my video with UT Codec (in 4:2:0 mode, ULY0). When I examine the output file with MediaInfo it tells me the video is YUV 4:2:2. When I use Info() in Avisynth it tells me the color space is YUV 4:2:0.

I'm doing the best I can to avoid any color conversions. At this point, I'm not sure if MediaInfo is misreporting the color space, or if UT Codec is damaging the file somehow, or is Avisynth is misreporting the information.

I've tried posting in the UT Codec thread but I haven't been able to get a response from anyone.

Any help would be much appreciated.
If so, then UT Codec is encoding to YUV 4:2:2

[poisondeathray]

mediainfo is mistaken

[Emulgator]

mediainfo is mistaken
Confirm that.

[poisondeathray]

Confirm that.



Is that a request or agreement?

I've confirmed it with UT 8.5

[Emulgator]

Oops, sorry, I meant "I can confirm that".

With UT 8.5.0 as ULY0 and mediainfo 0.7.41.

...too short can be rude sometimes.
poisondeathray, please accept my apologies.

[poisondeathray]

no problem Emulgator :)

@Fullmetal Encoder - you can prove this yourself by taking a RGB format (something with red on green) and encoding 422 and 420 versions using UT and pixel peeping. Another clue is that the 422 version has higher bitrate. You can compare this to uncompressed 422 and 420 versions.

If you think UT is "doing something" to your processing chain, take uncompressed 4:2:0 and compare using difference mask with the UT 4:2:0 version - you will see they are identical . (If you're using vdub to do the encoding, make sure you use video=>fast processing mode , or else you will incur Y'CbCr => RGB => Y'CbCr conversion. "Full Processing Mode" will decompress to RGB)

[Robert Martens]

If you're using vdub to do the encoding, make sure you use video=>fast processing mode , or else you will incur Y'CbCr => RGB => Y'CbCr conversion. "Full Processing Mode" will decompress to RGB

Is this still true? The VirtualDub help file, under Processing->The pipeline, states that this behavior has changed, and Full Processing mode now behaves the same way Normal Processing mode does (which itself lets you choose input/output color formats, but otherwise is the same as Fast Recompress) as long as you don't use any filters.

Scroll past the blue/green pipeline chart in that help topic, down to "Convert to 32-bit RGB" and you'll see this:

In previous versions of VirtualDub, enabling full processing mode would always force a conversion to 32-bit RGB. This is no longer the case — if no video filters are used, this conversion step is omitted and the video is directly converted to the output format as in Normal Recompress mode.

I've seen this note in at least the past couple of releases, am I to understand it's mistaken?

[poisondeathray]

Not sure - vdub behaviour might have changed . I'm 100% certain it used to be that way

But it certainly doesn't hurt to set "fast recompress" if you're not using vdub filters. This way you are 100% certain that you incur no other conversions

If you're very curious you can do some tests to prove/disprove it quite easily

[Robert Martens]

Oh, yes, definitely; I remember that too, and I'd make the same recommendation in any event. Just thought I'd ask in case there were any known issues with the documentation in regard to these conversions.