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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th May 2014, 17:13   #1  |  Link
Sp00kyFox
Registered User
 
Sp00kyFox's Avatar
 
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")
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.
Sp00kyFox is offline   Reply With Quote
Old 25th May 2014, 22:01   #2  |  Link
SEt
Registered User
 
Join Date: Aug 2007
Posts: 374
Convert to YV24, upscale luma, merge.
SEt is offline   Reply With Quote
Old 25th May 2014, 22:34   #3  |  Link
Sp00kyFox
Registered User
 
Sp00kyFox's Avatar
 
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.
Sp00kyFox is offline   Reply With Quote
Old 25th May 2014, 23:25   #4  |  Link
SEt
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.
SEt is offline   Reply With Quote
Old 26th May 2014, 01:34   #5  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 300
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.
Aktan is offline   Reply With Quote
Old 26th May 2014, 08:23   #6  |  Link
Sp00kyFox
Registered User
 
Sp00kyFox's Avatar
 
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.
Sp00kyFox is offline   Reply With Quote
Old 26th May 2014, 14:10   #7  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 300
Quote:
Originally Posted by Sp00kyFox View Post
...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.
Aktan is offline   Reply With Quote
Old 26th May 2014, 19:39   #8  |  Link
SEt
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.
SEt is offline   Reply With Quote
Old 26th May 2014, 22:52   #9  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 300
Quote:
Originally Posted by SEt View Post
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.

Last edited by Aktan; 26th May 2014 at 23:13.
Aktan is offline   Reply With Quote
Old 27th May 2014, 09:18   #10  |  Link
SEt
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.
SEt is offline   Reply With Quote
Old 27th May 2014, 16:01   #11  |  Link
Aktan
Registered User
 
Join Date: Feb 2002
Posts: 300
Quote:
Originally Posted by SEt View Post
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.
Aktan is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 05:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.