RGB32 -> YV12, keeping chroma information by 2xpoint?

[Sp00kyFox]

hi there. can someone explain me what I'm doing wrong. just playing around with some game footage encoding tests. I thought by doubling the resolution with pointresize and then converting it to yv12 the result should be colorwise the same as converting the original resolution to yv24. but in the result I can clearly see color mergings at pixel borders despite the chromaresample="point" argument (I'm using avisynth 2.6.0). here is the script I used:

AviSource("sample.avi") #RGB clip
PointResize(2*last.width, 2*last.height)
ConvertToYV12(chromaresample="point", matrix="PC.601")

clip sample (MSU Screen Capture Lossless Codec):
https://anonfiles.com/file/4826998bd17c2a89f0b1c44cbcaea109

magnified screenshots to demonstrate the color issue:
https://imgur.com/a/PnGqt

already tried using the chromaoutplacement argument, but like one would expect (cuz of 2xpoint) there is no difference.

[SEt]

Convert to YV24, upscale luma, merge.

[Sp00kyFox]

thanks for the idea but an actual script would be helpful. I obviously cannot use mergechroma() because of the different resolution/colorspace. I tried it with splitting the picture into it's luma and color planes but the end result is the same as before:

AviSource("sample.avi")
ConvertToYV24(chromaresample="point", matrix="PC.601")
u = UToY()
v = VToY()
YToUV(u, v, PointResize(2*last.width, 2*last.height))

[SEt]

Here chroma is obviously untouched, but it doesn't mean that reverse conversion YV12->RGB as you watch the video would do the same "lossless" point resize.

Edit: This code do what you likely want, but the final step in your player would be different

ConvertToYV24(matrix="PC.601")
YToUV(UToY(), VToY(), PointResize(2*last.width, 2*last.height, src_left=0.25, src_top=-0.25))
ConvertToRGB24(chromaresample="point", matrix="PC.601")

[Aktan]

Nice answer SEt. What I don't get in your sample code is why you did "src_left=0.25, src_top=-0.25". I kind of understand src_top=-.25, but since default placement in Avisynth is MPEG2, wouldn't it just be src_top=-0.5? At least in my limited test that also seems to work.

Edit: For MPEG1 placement, this seems to work:


ConvertToYV24(matrix="PC.601")
YToUV(UToY(), VToY(), PointResize(2*last.width, 2*last.height, src_left=-0.5, src_top=-0.5))
ConvertToRGB32(chromaresample="point", matrix="PC.601", ChromaInPlacement="MPEG1")

[Sp00kyFox]

lol, must've been to tired yesterday to see that I don't need to use variables. ok the process is reversible. what irritates me is why you can still see some color blendings in the yv12 intermediate step.

well I think the problem is actually how the chroma plane in yv12 is upscaled to the luma resolution and that's dependend on the decoder/application/video renderer. I'm visually checking my scripts with virtualdub, seems I tried to fix something what wasn't wrong in the first place.

thanks for the help!

[Aktan]

...what irritates me is why you can still see some color blendings in the yv12 intermediate step.

well I think the problem is actually how the chroma plane in yv12 is upscaled to the luma resolution and that's dependend on the decoder/application/video renderer. I'm visually checking my scripts with virtualdub, seems I tried to fix something what wasn't wrong in the first place.

thanks for the help!

Exactly. It's what SEt also said. You can't always control how it is upscaled and to make matters worse, a pure YUV stream has no standard that can tell a decoder how it was downscaled.

[SEt]

Aktan, src_top=-0.25 is the middle of the range [-0.5 .. 0.0), src_left is indeed not needed.

I've also made it for MPEG1 placement first as it seemed more logical, but as software would likely interpret that resolution as MPEG2 – went with MPEG2 in the end.

[Aktan]

Aktan, src_top=-0.25 is the middle of the range [-0.5 .. 0.0)...

I guess what I'm asking is why did you put it in the middle of that range instead of just -0.5. I might have the wrong understanding of the crop which is why I am confused.

[SEt]

Aktan, well, since we are operating floating point numbers and point resize works in discrete steps with -0.5 being a border value, my usual way of thoughts is to choice middle of the range instead of a border to avoid potential rounding errors. Not that we have any at -0.5 here though.

[Aktan]

Aktan, well, since we are operating floating point numbers and point resize works in discrete steps with -0.5 being a border value, my usual way of thoughts is to choice middle of the range instead of a border to avoid potential rounding errors. Not that we have any at -0.5 here though.

Ah, I was kind of thinking it was rounding related. Okay, thanks for the clarification and sorry for the off topic.