4:4:4

[juGGaKNot]

So it is here, finally :)

How can i encode/decode the content ?

My input is Format : RGB
Codec ID : RGB
Codec ID/Info : Uncompressed RGB32
Duration : 7s 958ms
Bit rate : 1 593 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16/9
Frame rate : 24.000 fps
Resolution : 32 bits
Bits/(Pixel*Frame) : 32.001

AVS ( installed 2.6.0 alpha 3 + the updated dll from 19.07.2011 )

Old script :

AVIsource("D:\x264\movie.avi")
Crop(0, height%2, -width%2, 0)
ConvertToYV12()

Here i should change YV12 to YV24 no ?

As for x264 ( latest 8 bit version ) just add --profile high10 ?

thnx.

[Chikuzen]

minimum requirement
x264 --demuxer lavf --output-csp i444 -o output.h264 input.avi

4:4:4 accepts odd resolution. and swscale convert RGB32 to i444 automatically.

Recommended players are LATEST VLC, MPlayer or MPlayer2.

[juGGaKNot]

minimum requirement
x264 --demuxer lavf --output-csp i444 -o output.h264 input.avi

4:4:4 accepts odd resolution. and swscale convert RGB32 to i444 automatically.

Recommended players are LATEST VLC, MPlayer or MPlayer2.

I get :

lavf [info]: 1024x576p 0:1 @ 60/1 fps (vfr)
resize [warning]: converting from bgra to yuv444p
[swscaler @ 0190a000] full chroma interpolation for destination format 'yuv444p'
not yet implemented
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [error]: ratecontrol_init: can't open stats file
x264 [error]: x264_encoder_open failed

--demuxer lavf --output-csp i444 --pass 1 --preset placebo --aud

[Chikuzen]

x264 [error]: ratecontrol_init: can't open stats file
This is not related 4:4:4 feature.
post your all command lines.

[juGGaKNot]

Yes, it was my mistake, left --pass 2 instead of --pass 1.

lavf [info]: 1024x576p 0:1 @ 60/1 fps (vfr)
resize [warning]: converting from bgra to yuv444p
[swscaler @ 0190a000] full chroma interpolation for destination format 'yuv444p'
not yet implemented
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 3.2, 4:4:4 8-bit
[3.9%] 35/902 frames, 0.49 fps, 6238.30 kb/s, eta 0:29:35

Now i will wait to see the difference.

[juGGaKNot]

lavf [info]: 1024x576p 0:1 @ 60/1 fps (vfr)
resize [warning]: converting from bgra to yuv444p
[swscaler @ 0190a020] full chroma interpolation for destination format 'yuv444p'
not yet implemented
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 3.2, 4:4:4 8-bit
x264 [info]: frame I:4 Avg QP:19.89 size: 51529
x264 [info]: frame P:282 Avg QP:23.61 size: 18198
x264 [info]: frame B:616 Avg QP:25.71 size: 6531
x264 [info]: consecutive B-frames: 6.0% 9.3% 19.6% 30.2% 34.9%
x264 [info]: mb I I16..4: 51.4% 0.0% 48.6%
x264 [info]: mb P I16..4: 30.1% 0.0% 0.0% P16..4: 47.1% 0.0% 0.0% 0.0% 0
.0% skip:22.9%
x264 [info]: mb B I16..4: 9.2% 0.0% 0.0% B16..8: 30.1% 0.0% 0.0% direct:
12.4% skip:48.3% L0:37.0% L1:42.9% BI:20.1%
x264 [info]: final ratefactor: 18.89
x264 [info]: direct mvs spatial:99.4% temporal:0.6%
x264 [info]: coded y,u,v intra: 33.5% 1.0% 0.8% inter: 22.0% 2.0% 1.0%
x264 [info]: i16 v,h,dc,p: 29% 33% 24% 15%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 25% 13% 4% 11% 5% 12% 6% 12%
x264 [info]: Weighted P-Frames: Y:20.6% UV:19.9%
x264 [info]: kb/s:4981.58

encoded 902 frames, 4.25 fps, 4981.58 kb/s
lavf [info]: 1024x576p 0:1 @ 60/1 fps (vfr)
resize [warning]: converting from bgra to yuv444p
[swscaler @ 0190a020] full chroma interpolation for destination format 'yuv444p'
not yet implemented
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 3.2, 4:4:4 8-bit
x264 [info]: frame I:4 Avg QP:23.41 size: 44490
x264 [info]: frame P:282 Avg QP:25.06 size: 17479
x264 [info]: frame B:616 Avg QP:27.57 size: 6851
x264 [info]: consecutive B-frames: 6.0% 9.3% 19.6% 30.2% 34.9%
x264 [info]: mb I I16..4: 2.9% 88.9% 8.2%
x264 [info]: mb P I16..4: 5.9% 18.4% 1.6% P16..4: 36.9% 17.7% 0.7% 0.0% 0
.0% skip:18.8%
x264 [info]: mb B I16..4: 0.8% 3.1% 0.2% B16..8: 37.4% 9.1% 2.4% direct:
6.6% skip:40.5% L0:45.4% L1:43.6% BI:11.0%
x264 [info]: 8x8 transform intra:73.0% inter:81.6%
x264 [info]: direct mvs spatial:95.9% temporal:4.1%
x264 [info]: coded y,u,v intra: 63.8% 12.6% 9.0% inter: 23.5% 3.3% 1.9%
x264 [info]: i16 v,h,dc,p: 27% 24% 12% 37%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 10% 8% 8% 14% 10% 19% 8% 16%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 8% 12% 3% 6% 16% 10% 22% 8% 16%
x264 [info]: Weighted P-Frames: Y:20.6% UV:19.9%
x264 [info]: ref P L0: 53.5% 17.7% 14.7% 7.8% 4.7% 1.3% 0.2%
x264 [info]: ref B L0: 79.8% 14.5% 4.4% 1.3%
x264 [info]: ref B L1: 91.5% 8.5%
x264 [info]: kb/s:4963.69

encoded 902 frames, 1.95 fps, 4963.69 kb/s
AVC-H264 import - frame size 16 x 192 at 60.000 FPS
Import results: 902 samples - Slices: 4 I 282 P 616 B - 1 SEI - 4 IDR
IsoMedia import - track ID 1 - Audio (SR 44100 - 2 channels)
Saving C:\x264\Movie\1.Movie_X264_2D.mp4: 0.500 secs Interleaving


General
Complete name : C:\x264\Movie\1.Movie_X264_2D.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 9.26 MiB
Duration : 15s 92ms
Overall bit rate : 5 144 Kbps
Genre : PS3 Compatible
Encoded date : UTC 2011-07-24 13:57:21
Tagged date : UTC 2011-07-24 13:57:21

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L3.2
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 15s 33ms
Bit rate mode : Variable
Bit rate : 4 900 Kbps
Maximum bit rate : 11.7 Mbps
Width : 16 pixels
Original width : 1 024 pixels
Height : 192 pixels
Original height : 576 pixels
Display aspect ratio : 0.083
Original display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 26.584
Stream size : 8.89 MiB (96%)
Writing library : x264 core 116 r2037 f8ebd4a
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=4 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=4 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=600 / keyint_min=60 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=4900 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=2:1.00
Encoded date : UTC 2011-07-24 13:57:21
Tagged date : UTC 2011-07-24 13:57:22

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 15s 92ms
Bit rate mode : Variable
Bit rate : 192 Kbps
Maximum bit rate : 211 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 359 KiB (4%)
Encoded date : UTC 2011-07-24 13:57:22
Tagged date : UTC 2011-07-24 13:57:22

The video has audio and a vertical strip of video.

[Chikuzen]

AVC-H264 import - frame size 16 x 192 at 60.000 FPS
this is wierd.
maybe, you made a mistake in the usage of mp4box.

[juGGaKNot]

Yes, used mkvtoolnix and it works.

mp4box works also with the output 4:2:0 but not 4:4:4

LE : latest version of mp4box seems to work fine.

[Lyris]

Out of curiosity, what's your 4:4:4 source? Video game captures?

[juGGaKNot]

Yes, counter strike 1.6

It looks good but not perfect so far, i will post screens.

LE : ahh, nvm, it looks the same, the prev frame had more frame blending.

[LilScrappy]

Please for help i use Avisynth 2.6.0 Alpha 4 and MeGui and custom command line --output-csp i444 but have this error message any chance to fix ?

--[Warning] [10/4/2013 9:25:16 AM] Standard error stream
---[Warning] [10/4/2013 9:25:17 AM] resize [warning]: converting from yuv420p to yuv444p

[the_weirdo]

Please for help i use Avisynth 2.6.0 Alpha 4 and MeGui and custom command line --output-csp i444 but have this error message any chance to fix ?

Are you sure your Avisynth script output is YV24? From that warning, for some reason it has been recognized as YV12.

[LilScrappy]

i add now in script ConvertToYV24 after start encode from megui have message:
i click no
http://i.imgur.com/iXbuNiZ.jpg
after that i have this message and click yes
http://i.imgur.com/cwk2UVM.jpg
and in megui log no have error more, all right now or ?

--[Information] [10/4/2013 10:32:29 AM] Standard error stream
---[Information] [10/4/2013 10:32:30 AM] raw [info]: 1920x1080p 1:1 @ 24000/1001 fps (cfr)
---[Information] [10/4/2013 10:32:30 AM] x264 [info]: using SAR=1/1
---[Information] [10/4/2013 10:32:30 AM] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
---[Information] [10/4/2013 10:32:30 AM] x264 [info]: profile High 4:4:4 Predictive, level 5.1, 4:4:4 10-bit
---[Information] [10/4/2013 10:32:30 AM] x264 [info]: frame I:1 Avg QP:33.01 size:110363
---[Information] [10/4/2013 10:32:30 AM] x264 [info]: mb I I16..4: 10.3% 83.0% 6.7%
---[Information] [10/4/2013 10:32:30 AM] x264 [info]: 8x8 transform intra:83.0%
---[Information] [10/4/2013 10:32:30 AM] x264 [info]: coded y,u,v intra: 77.5% 54.6% 40.7%
---[Information] [10/4/2013 10:32:30 AM] x264 [info]: i16 v,h,dc,p: 16% 13% 21% 50%
---[Information] [10/4/2013 10:32:30 AM] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 8% 6% 9% 11% 14% 11% 11% 10%
---[Information] [10/4/2013 10:32:30 AM] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 7% 2% 9% 15% 18% 13% 11% 10%
---[Information] [10/4/2013 10:32:30 AM] x264 [info]: kb/s:21168.53
---[Information] [10/4/2013 10:32:30 AM] encoded 1 frames, 1.35 fps, 21168.53 kb/s

[Gavino]

All you have actually achieved is to have the conversion from YV12 to YV24 now done inside Avisynth instead of inside x264.

But it seems to me that unless your source really is 4:4:4 (or RGB), there is little to be gained from converting the output to YV24.

What is your source and complete script?

[LilScrappy]

the source is YV12, my script is simple:
FFVideoSource("F:\Program\eac3to v3.24\Star Wars The Clone Wars\episode 1\video.mkv", fpsnum=24000, fpsden=1001)
Spline36Resize(1920,1080) # Spline36 (Neutral)
ConvertToYV24
or i need more thing on script for change correctly YV12 to YV24 ?
in megui custom command line i use --output-csp i444 and for color matrix - bt709

[Gavino]

The script correctly converts YV12 to YV24, but the question is, what is the point?

Conversion to YV24 cannot magically provide any greater real chroma resolution than you have in the source, so why not leave it as YV12?

[LilScrappy]

You telling me what i use 4:2:2 or 4:4:4 for output, when source is 4:2:0 no see visible difference even minimal ?

[feisty2]

http://nmm-hd.org/newbbs/viewtopic.php?f=7&t=1117
you can use this script to convert yv12 source to yv24,the quality is much better than players chroma upscaling (even better than madVR)

[LilScrappy]

feisty2
please give me simple script for test i dont understand chinese !

[the_weirdo]

Does it improve much and is it worth?

Converting YV12 to YV24 means you have to reencode the video (if you're going to do it anyway then this is not a problem, but YUV 4:4:4 encoding takes more time than YUV 4:2:0). You can't use hardware-accelerated decoding to decode YUV 4:4:4 H.264 (EDIT: I've just realized he's using 10-bit so this statement is irrelevant), while YUV 4:4:4 decoding in software mode needs more CPU processing power (about 40%, IIRC) comparing to YUV 4:2:0 content. MadVR has good enough chroma upsamplers, for example: Jinc. For chroma upsampling, there should not much difference between Jinc and NNEDI3, and they're both overkill. Remember that chroma doesn't have much detail to begin with.

[bxyhxyh]

I think converting 1080p 4:2:0 to 1080p 4:4:4 has no gains.
But some fansub teams doing 720p 4:4:4 encode. And they look very different from 720p 4:2:0.
I'm sure they're downscaling 1080p to 720p.
But what is the magic? Or just they're using ConvertToYV24 before resize?

[the_weirdo]

I think the right way to do is by resizing chroma and luma independently (this way you can also choose better resampler for each plane), then merge them together. By ConvertToYV24 and then resize, you've resized chroma 2 times.

Maybe something like this:

YV12_Source
Y = ConvertToY8().Resize(w, h)
U = UToY8().Resize(w, h)
V = VToY8().Resize(w, h)
YToUV(U, V, Y)

[Gavino]

I think the right way to do is by resizing chroma and luma independently (this way you can also choose better resampler for each plane), then merge them together. By ConvertToYV24 and then resize, you've resized chroma 2 times.
Yes, that makes sense.
Basically, you downsize the luma but upscale the chroma, preserving as much as possible of the original information.

[bxyhxyh]

I compared two fansub teams' encodes.
http://check2pic.ru/compare/31737
First one is encoded in 4:2:0 other one is encoded 4:4:4
I'm not sure about if they've used tweak filters or not.

[raffriff42]

@the_weirdo - YToUV - great idea. Cuts down on the resizing, as you mention.

Here's a working script using your idea. Note chroma offset is something that needs to be addressed. I do this with Overlay - might not be the best way to do it. EDIT - probably should offset *before* resizing

## clip C = YV12 or YUY2
new_wid = 848 ## set resize width
new_hgt = 480 ## set resize height

## jog frame-by-frame to compare resizing quality
## ** not for real time playback **
return Interleave(
\ C.BilinearResize(new_wid, new_hgt).ConvertToYV24()
\ .Subtitle( "bilin" , align=8, size=56),
\ C.Spline16Resize(new_wid, new_hgt).ConvertToYV24()
\ .Subtitle( "Spline16" , align=8, size=56),
\ C.ConvertYxxToYV24_UToY8(new_wid, new_hgt, sharpen=false)
\ .Subtitle( "UToY8 sharp=off" , align=8, size=56),
\ C.ConvertYxxToYV24_UToY8(new_wid, new_hgt, sharpen=true)
\ .Subtitle( "UToY8 sharp=on" , align=8, size=56))

##################################
### attempt to enhance chroma detail on YV12/YUY2 sources
##
## @ out_w = output width; default = source width
## @ out_h = output height; default = source height
## @ chr_x = chroma offset; default = -1 (move left by 1 pixel)
## @ chr_y = chroma offset; default = 0 (no change)
## @ sharpen = if True, add sharpening (default=true)
##
function ConvertYxxToYV24_UToY8(clip C,
\ int "out_w", int "out_h",
\ int "chr_x", int "chr_y",
\ bool "sharpen")
{
Assert(C.IsYV12||C.IsYUY2, "source must be YV12 or YUY2")
out_w = Default(out_w, C.Width)
out_h = Default(out_h, C.Height)
chr_x = Default(chr_x, -1)
chr_y = Default(chr_y, 0)
sharpen = Default(sharpen, true)

Y = C.ConvertToY8().Spline16Resize(out_w, out_h)
U = C.UToY8()
V = C.VToY8()

U = U.Spline16Resize(out_w, out_h)
V = V.Spline16Resize(out_w, out_h)

## vertical sharpening does no good at this stage:
## (YUY2 does not need it and YV12 has nothing to enhance)
U = (sharpen==false) ? U : U.Sharpen(1.0, 0.0)
V = (sharpen==false) ? V : V.Sharpen(0.6, 0.0)
## (less V sharpening as overshoot more visible in V channel)

## chroma offset (TODO: try moving this before resize)
U = (chr_x==0 && chr_y==0) ? U : U.Overlay(U, x=chr_x, y=chr_y)
V = (chr_x==0 && chr_y==0) ? V : V.Overlay(V, x=chr_x, y=chr_y)

return YToUV(U, V, Y)
}

[bxyhxyh]

This is a code I found, combined with Debilinear filter.

loadplugin("dither.dll")
import("dither.avsi")
loadplugin("debilinear.dll")
#YV12 source
dither_convert_8_to_16()
ly = debilinear(1280, 720, lsb_inout=true)
lc = dither_resize16(1280*2, 720*2, src_left=0.25, kernel="spline36")
lu = lc.utoy()
lv = lc.vtoy()
ytouv(lu,lv,ly)
DitherPost()

It seems user can play with invks, invksh, invksv arguments to "undo" a previous BilinearResize effect.

But why 0.25? What is it for?

[Gavino]

Note chroma offset is something that needs to be addressed. I do this with Overlay - might not be the best way to do it. EDIT - probably should offset *before* resizing
The correct way is to use the offset (src_left, src_top) parameters of the resize itself (and remove Overlay).
U = U.Spline16Resize(out_w, out_h, chr_x, chr_y)
V = V.Spline16Resize(out_w, out_h, chr_x, chr_y)
The correct values for chr_x and chr_y are tricky to work out and depend on the input colorspace (YV12 or YUY2) and the resizing ratios. You have to take into account both chroma placement and the fact that Avisynth resizing preserves the image center position, not the corner.

I believe these are correct:
chr_x = 0.25*in_w/out_w (for YV12 and YUY2)
chr_y = 0.25*(in_h/out_h - 1) (for YV12), zero for YUY2

[raffriff42]

Awesome, Gavino - confirmed your chroma offset code works whether downsizing or not. I was worried about artifacts at the borders, but I don't see any.

Here's my revised routine ##################################
### attempt to enhance chroma detail on YV12/YUY2 sources
### ver 2
### thanks: the_weiro, Gavino
### http://forum.doom9.org/showthread.php?p=1647152
##
## @ out_w = output width; default = source width
## @ out_h = output height; default = source height
## @ sharpen = if True, add sharpening (default=true)
##
function ConvertYxxToYV24_UToY8(clip C,
\ int "out_w", int "out_h",
\ bool "sharpen")
{
Assert(C.IsYV12||C.IsYUY2, "source must be YV12 or YUY2")
out_w = Default(out_w, C.Width)
out_h = Default(out_h, C.Height)
sharpen = Default(sharpen, true)

chr_x = 0.25 * C.Width / out_w
chr_y = C.IsYUY2 ? 0.0 : 0.25 * (Float(C.Height) / out_h - 1)

Y = C.ConvertToY8().Spline36Resize(out_w, out_h)
U = C.UToY8().Spline16Resize(out_w, out_h, chr_x, chr_y)
V = C.VToY8().Spline16Resize(out_w, out_h, chr_x, chr_y)

## vertical sharpening doesn't do much at this stage:
## (YUY2 does not need it and YV12 has nothing to enhance)
U = (sharpen==false) ? U : U.Sharpen(0.6, 0.3)
V = (sharpen==false) ? V : V.Sharpen(0.3, 0.0) ## overshoot more visible in V channel

return YToUV(U, V, Y)
}

[Gavino]

Awesome, Gavino - confirmed your chroma offset code works whether downsizing or not.
Thanks - I hadn't tested it, just worked it out on the back of an envelope (literally!).

A small fix:
chr_y = C.IsYUY2 ? 0.0 : 0.25 * (C.Height / out_h - 1)
needs to be
chr_y = C.IsYUY2 ? 0.0 : 0.25 * (float(C.Height) / out_h - 1)

[Gavino]

I hadn't tested it, just worked it out on the back of an envelope (literally!).
I've had another look at the envelope and I think there was a mistake in my derivation.
I now think the required offsets are independent of the resizing ratios, and are the same for both YUY2 and YV12, namely

chr_x = 0.25
chr_y = 0

I suspect that is consistent with the 0.25 used in bxyhxyh's post, but I don't know enough about his method to say whether it is effectively doing the same thing.

[IanB]

@raffriff42,

Rather than use the Sharpen filter with Spline16Resize for the chroma, you may get superior result using BicubicResize and tuning the B and C values for sharpening. Sharpening in the resizer can use more pixels in the "sharp" interpolation calculation and give a more precise result, and also avoid the time that would be spent in the separate sharpen filter.

@Gavino,

Yes the chr_x offset is proportional to the difference in resize ratios between luma and chroma. It is 0.25 for 2:1 (YUY2, Mpeg2 YV12) and 0.5 for 4:1 (NTSC DV YV411)

[raffriff42]

@IanB, good question, but I find downsizing with anything other than bilinear or spline36 or spline64 results in aliasing (aka twittering, shimmering), which I personally dislike. I'd rather downsize as accurately as possible and add sharpening later. With some soft source material aliasing might not be a problem, I don't know.

Here's a script which I've been using to compare all the resizing methods. It is for frame by frame comparison - not real time playback! #avisynth

## (there will be no autoloading in this house, young man...)
LoadPlugin(pathBase + "debilinear\debilinear.dll")
Import(pathBase + "Dither\dither.avsi")

o420=ImageSource("colorsub-wiz-768x520-420.png")
new_wid = 520
new_hgt = 352

X = o420.ConvertToYV12(matrix="Rec709")
X4 = X.ConvertToYV24
return Interleave(
\ X4.PointResize(new_wid, new_hgt)
\ .xSub("Point"),
\ X4.BilinearResize(new_wid, new_hgt)
\ .xSub("Bilin"),
\ X4.BilinearResize(new_wid, new_hgt).Sharpen(0.3)
\ .xSub("Bilin+0.3"),
\ X4.BilinearResize(new_wid, new_hgt).Sharpen(0.6)
\ .xSub("Bilin+0.6"),
\ X.DebilinResize(new_wid, new_hgt)
\ .xSub("Debilin"),
\ X4.BicubicResize(new_wid, new_hgt)
\ .xSub("Bicub"),
\ X4.SincResize(new_wid, new_hgt)
\ .xSub("Sinc"),
\ X4.BlackmanResize(new_wid, new_hgt)
\ .xSub("Blackman"),
\ X4.LanczosResize(new_wid, new_hgt)
\ .xSub("Lanczos"),
\ X4.Lanczos4Resize(new_wid, new_hgt)
\ .xSub("Lanczos4"),
\ X4.Spline16Resize(new_wid, new_hgt)
\ .xSub("Spline16"),
\ X4.Spline36Resize(new_wid, new_hgt)
\ .xSub("Spline36"),
\ X4.Spline64Resize(new_wid, new_hgt)
\ .xSub("Spline64"),
\ X4.Spline64Resize(new_wid, new_hgt).Sharpen(0.2)
\ .xSub("Spline64+0.2"),
\ X.ConvertYxxToYV24_UToY8v4(new_wid, new_hgt)
\ .xSub("UToY8v4"),
\ X.DebilinResize(new_wid, new_hgt)
\ .xSub("Debilin"),
\ X4.BicubicResize(new_wid, new_hgt)
\ .xSub("Bicub"),
\ X4.PointResize(new_wid, new_hgt)
\ .xSub("Point"))

##################################
function xSub(clip C, string s)
{
return C.Subtitle(s, align=8, size=42)
}

##################################
## http://forum.doom9.org/showthread.php?p=1647176#post1647176
## (@bxyhxyh)
function DebilinResize(clip C, new_wid, new_hgt)
{
Assert(C.IsYV12, "DebilinResize: source must be YV12")
C
dither_convert_8_to_16()
ly = debilinear(new_wid, new_hgt, lsb_inout=true)
lc = dither_resize16(new_wid*2, new_hgt*2, src_left=0.25, kernel="spline36")
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
return DitherPost()
}

##################################
### convert YV12/YUY2 sources to YV24 with best chroma resolution
### output = YV24
### ver 4
### thanks: the_weirdo, Gavino, ...
### http://forum.doom9.org/showthread.php?p=1647152
##
## @ out_w = output width; default = source width
## @ out_h = output height; default = source height
## @ sharpY = optional post-resize processing (range=-1.0 to 1.0; default=0.1)
## @ sharpC = optional post-resize processing (range= 0.0 to 1.0; default=0.6)
##
function ConvertYxxToYV24_UToY8v4(clip C,
\ int "out_w", int "out_h",
\ float "sharpY", float "sharpC")
{
Assert(C.IsYV12||C.IsYUY2, "ConvertYxxToYV24_UToY8v4: source must be YV12 or YUY2")
out_w = Default(out_w, C.Width)
out_h = Default(out_h, C.Height)
sharpY = Min(Max(-1.0, Float(Default(sharpY, 0.1))), 1.0)
sharpC = Min(Max(0.0, Float(Default(sharpC, 0.6))), 1.0)

chr_x = 0.25 * C.Width / out_w
chr_y = 0.0

Y = C.ConvertToY8().Spline36Resize(out_w, out_h)
U = C.UToY8().Spline16Resize(out_w, out_h, chr_x, chr_y)
V = C.VToY8().Spline16Resize(out_w, out_h, chr_x, chr_y)

U = (sharpC<0.01) ? U : U.Sharpen(sharpC, sharpC/2.0)
V = (sharpC<0.01) ? V : V.Sharpen(sharpC/2.0, sharpC/4.0)
Y = Y.Sharpen(sharpY)

return YToUV(U, V, Y)
} As far as which one is "best," of course that depends on the viewer and the source. So far, I like the routine I have posted above, but the look is almost identical to the much easier-to-use ConvertToYV24 > Spline64Resize > Sharpen(0.2)

I have been using a variety of images to test, but here's a pretty good one (JPEG preview - click for PNG):
https://www.dropbox.com/s/au1plzi1ae5f7m9/colorsub-wiz-768x520-420.jpg?raw=1 (https://www.dropbox.com/s/ztzabijo4ilqlfg/colorsub-wiz-768x520-420.png)
The above 4:2:0 image was made by processing this RGB original (https://www.dropbox.com/s/g5z3kgra62vp3n0/colorsub-wiz-768x520-444.png) with VirtualDub's chroma smoother filter (mode=4:2:0, MPEG-2).
(top part cropped from an ISO 12233 Chart (https://www.google.com/search?q=iso+12233+chart) and repeated in red, green and blue; middle part cropped from here (https://sourceforge.net/projects/frafstestpatt/); bottom part originally from this post (http://forum.doom9.org/showthread.php?p=1550176))

[Gavino]

chr_x = 0.25 * C.Width / out_w
As I said in post #30 (and confirmed by IanB), this should be simply chr_x = 0.25

I was mistaken when I originally said that the value depended on the ratio of input and output width.

[IanB]

@raffriff42,

Yes keep the Spline36/64Resize for the luma channel, if that is what you like.

I was suggesting you try replacing the chroma Spline16Resize(...).Sharpen(...) case with a BicubicResize(..., b=?, c=?), with b and c chosen from the sharp side of the street.

Bicubic and Spline16 are the same order resizers, and for some value of b and c they would be virtually indistinguishable. The standard b=1/3, c=1/3 is not it, Spline16 appears to be ever so slightly sharper.

[TheSkiller]

chr_x = 0.25
chr_y = 0

Now I'm confused.
In this older post you determined it to be 0.5 for YV12/YUY2 horizontal resizing:

Hence the net (rightwards) chroma shift is a distance of 0.5*(1-Win/Wout) input luma pixels.
(Clicking the arrow links to that post.)

[Gavino]

Now I'm confused.
In this older post you determined it to be 0.5 for YV12/YUY2 horizontal resizing
That post was about a different topic - the chroma shift resulting from a bug in Avisynth's horizontal resizers.
That doesn't arise here (in this thread), since the chroma is resized separately as Y8.
However, the underlying reasoning is similar and is based on what I also said in that other post.
For YV12 and YUY2, the chroma centre is 0.5 luma pixels to the left of the luma centre.
This directly leads to the result chr_x = 0.25, since the required offset chr_x must be measured in chroma pixels, which are twice as far apart as luma ones.

[TheSkiller]

I see, thanks for clarifying it. I hadn't quite wrapped my mind around the issue with separated chroma in the form of Y8. :o

[bxyhxyh]

For YV12 and YUY2, the chroma centre is 0.5 luma pixels to the left of the luma centre.
This directly leads to the result chr_x = 0.25, since the required offset chr_x must be measured in chroma pixels, which are twice as far apart as luma ones.
Is it same for YV16?

[Gavino]

Is it same for YV16?
Yes. YV16 assumes MPEG-2 sampling (http://avisynth.nl/index.php/Sampling#mpeg-1_versus_mpeg-2_sampling), like YUY2 and YV12.

[bxyhxyh]

Sorry if i'm asking twice, my previous question meant that Should I shift chroma for YV12->YV16 conversion?

Since chroma width doesn't change, I think it shouldn't. Is it true?

[Gavino]

That's right, no need to shift chroma for YV12<->YV16 conversion. Horizontally, they have the same width and placement.
Vertically, they have different heights, but the centres of the sampling grids coincide, so normal resizing does the job properly.