Disadvantages of converting to RGB/YV24 in order to crop in odd numbers?

[bruno321]

I have a YV12 source (a .d2v gotten from a DVD via DGIndex) and I've never cropped in odd values because I thought it's not possible. I recently learned that it is possible upon conversion to RGB or to YV24, but I don't really know what this entails (also, apparently one should convert back to YV12 at the end?). The end-file is to be an x264 mkv.

My question is, are there any downsides to converting, cropping in odd numbers, and converting back? Is the image quality affected, is the playback compatibility affected, ...? Would there be a reason to prefer one of YV24 or RGB to the other?

If it matters, this is a hard-telecined NTSC source (one I want to run tfm().TDecimate() on), but I'm interested in other possibilities as well (progressive PAL, etc.)

Thanks!

[wonkey_monkey]

You can't convert back if you crop to a number of pixels which isn't supported by the original format. You can convert to YV24 and (I think) encode 4:4:4 x264, but is it really worth it - putting extra demand on your bitrate, and possibly causing playback issues - just to save one row or column of pixels?

[bruno321]

" is it really worth it - putting extra demand on your bitrate, and possibly causing playback issues "

Well, I didn't know those things, it's why I'm asking. Why does it put extra demand on the bitrate, and what kind of playback issues can it cause?

[wonkey_monkey]

You're quadrupling the amount of chroma pixels that need to be encoded - although they will mostly be interpolated anyway, it will still mean a reduction in quality for a given bitrate.

For playback, it's likely that a number of embedded players would be unable to play 4:4:4 because it's such an uncommon format.

[hello_hello]

You can crop an odd number of pixels without converting to a full chroma format by effectively cropping with a resizer. Naturally you can only do it if you're resizing.

This example would also require cropping a little over 5 pixels from the width to prevent aspect error, but if you wanted to crop 3 pixels from the top of a 1280x720 source and resize back to 1280x720:

Using Crop for as much of the cropping as possible.

Crop(2,2,-2,0)
Spline36Resize(1280,720, 0.67,1,-0.67,0)

Or you could do it all with the resizer:

Spline36Resize(1280,720, 2.67,3,-2.67,0)

Crop vs resizer cropping:
http://avisynth.nl/index.php/Resize#Cropping

Shameless plug:
https://forum.doom9.org/showthread.php?t=176667

Mind you mod2 cropping only requires cropping one additional row/column of pixels. It's nothing I'd worry about.

[MeteorRain]

Let me try it in simple words.

Due to human eyes, video files are encoded in YV12 or similar colorspace. This kind of space reduced the amount of chroma data (color) but preserve full luma data (brightness). Human eyes are not as sensitive to chroma as to luma.

Now suppose you have a YV12 image, 640x480. The luma plane has 640x480 full amount of data, but chroma only has 320x240.

If you want to cut 1 pixel from this, the luma plane becomes 639x480, which is fine. But chroma will be cut to 319.5x240, and we all know you can't cut pixels in half.

Now if you convert them into YV24, which means chroma will also have full amount of data -- 640x480, and then indeed you can cut 1 pixel from it.

But when you encode this video, you will be encoding 640x480+640x480+640x480 YV24 data into a 4:4:4 format, compared to 640x480+320x240+320x240 YV12, a lot of time and bitrate will be wasted on chroma planes that human eyes don't care as much.

[bruno321]

Thank you all very much for the comments. That was very informative -- I now understand it's not worth the hassle, and why it's not worth it :)

[Katie Boundary]

Thank you all very much for the comments. That was very informative -- I now understand it's not worth the hassle, and why it's not worth it :)

It's absolutely worth it, as long as you plan on resizing it back to an even number before converting back to YUV 4:2:0

Converting to RGB is also something you should do if you plan on doing any horizontal resizing, because of an AVIsynth bug.

[hello_hello]

Ignore Katie. She puts anyone on her ignore list who doesn't agree with her and as a result only she only learns a fraction of what she could.

The "Avisynth bug" she refers to means when resizing some formats with sub-sampled chroma such as YV12, the Avisynth resizers can shift the chroma just a fraction relative to the luma.
http://avisynth.nl/index.php/Known_Issues#Resizers:_Chroma_Positioning_Bugs

If I remember correctly you have to upscale by 2x to shift the chroma by 1/4 of a pixel, and halving the resolution shifts the chroma by half a pixel, or something similar, but if you're concerned about it there's functions for resizing with Avisynth's resizers that correct the chroma shift so you don't need to convert to RGB to avoid it. I use Resize8 (http://avisynth.nl/index.php/Resize8) regularly and you can still use it for the type of non-mod or "sub-pixel cropping" I mentioned in my previous post. ie

Crop(2,2,-2,0)
Resize8(1280,720, 0.67,1,-0.67,0, Kernel="Spline36")