Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
25th May 2014, 17:13 | #1 | Link |
Registered User
Join Date: Aug 2007
Posts: 79
|
RGB32 -> YV12, keeping chroma information by 2xpoint?
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:
Code:
AviSource("sample.avi") #RGB clip PointResize(2*last.width, 2*last.height) ConvertToYV12(chromaresample="point", matrix="PC.601") 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. |
25th May 2014, 22:34 | #3 | Link |
Registered User
Join Date: Aug 2007
Posts: 79
|
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:
Code:
AviSource("sample.avi") ConvertToYV24(chromaresample="point", matrix="PC.601") u = UToY() v = VToY() YToUV(u, v, PointResize(2*last.width, 2*last.height)) Last edited by Sp00kyFox; 25th May 2014 at 22:57. |
25th May 2014, 23:25 | #4 | Link |
Registered User
Join Date: Aug 2007
Posts: 374
|
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 Code:
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") Last edited by SEt; 25th May 2014 at 23:43. |
26th May 2014, 01:34 | #5 | Link |
Registered User
Join Date: Feb 2002
Posts: 303
|
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: Code:
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") Last edited by Aktan; 26th May 2014 at 01:41. |
26th May 2014, 08:23 | #6 | Link |
Registered User
Join Date: Aug 2007
Posts: 79
|
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! Last edited by Sp00kyFox; 26th May 2014 at 08:30. |
26th May 2014, 14:10 | #7 | Link | |
Registered User
Join Date: Feb 2002
Posts: 303
|
Quote:
|
|
26th May 2014, 19:39 | #8 | Link |
Registered User
Join Date: Aug 2007
Posts: 374
|
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. |
27th May 2014, 09:18 | #10 | Link |
Registered User
Join Date: Aug 2007
Posts: 374
|
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.
|
27th May 2014, 16:01 | #11 | Link | |
Registered User
Join Date: Feb 2002
Posts: 303
|
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|