AddBorders function adds smudges

[dREV]

Hello, I am hoping somebody will be able to help me on this issue I have when using both functions of AddBorders() (8 bit and 16 bit) which is the sole cause of my problem or correct me on what I am doing wrong or if it's something else. Everything is fine until I add the AddBorders and I cannot figure out why.

AviSynth+ 32 bit ver 2772

Crop(0, 132, 0, -132)
ContinuityFixer(0, 2, 0, 2,radius=6)

# AddBorders(0, 132, 0, 132) # trial 1

dither_convert_8_to_16()

# Dither_addborders16(0, 132, 0, 132) #trial 2

s16 = last
DitherPost(mode=6)

# insert other 8 bit filter

dither_convert_8_to_16()
s16.Dither_limit_dif16 (last, thr=0.25, elast=4.0)

ly = DebilinearM(1280,544,thr=01,lsb_inout=true)
lc = nnedi3_resize16(1280*2, 544*2,lsb_in=true,lsb=true,kernel_d="Spline64",kernel_u="Spline64",src_top=0.0,src_left=0.50)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

# Dither_add_grain16 filter
# banding filter

# Dither_addborders16(0, 88, 0, 88) #trial 3
Dither_out()

The "trial" indicated above are where I've tried switching around. My video source is a letterbox and my purpose doing this is to not have the grain that's added for preventing banding onto the black border but leaving it clean as I prefer not to cut it off completely and of course for easier compression to final video size. The results I get for 720p version are as follow may have to zoom in.

From left to right following the script above:

Left - AddBorders() (8 bit)
Center - Dither_addborders16 (16 bit)
Right - My ideal result which I painted in the black border in image program

https://i.ibb.co/2jdLtvB/addborder8-avspmod.jpg https://i.ibb.co/PGy306m/addborder16-avspmod.jpg https://i.ibb.co/pLCxDM2/addborder-ideal-avspmod.jpg

As can see for some reason the AddBorders seeps into the picture by 2 pixel both top (not shown) and bottom. :eek: I've tried manipulating the script around as noted above to no avail, so I thought of just doing another resolution, 480p to increase my frustration. Changing a few scripts out/in.

:stupid:Y = ConvertToY8().dither_resize16(852,362,kernel="Spline36")
U = UToY8().dither_resize16(852, 362,kernel="blackmanminlobe",src_top=0.0,src_left=0.25)
V = VToY8().dither_resize16(852, 362,kernel="blackmanminlobe",src_top=0.0,src_left=0.25)
YToUV(U, V, Y)

Dither_addborders16(0, 59, 0, 59)

And the results on this are:

https://i.ibb.co/9H1K9Dk/addborder16-480p-avspmod.jpg https://i.ibb.co/MVPGYq0/addborder16-480p-b4-avspmod.jpg

The left one is when AddBorders is placed at the end of the script as can see it has the black ink-like smudges but it's very light which I've zoomed in a bit on both to be seen here since it's 480p and all but it's more pronounced on the 720p images above with the two different colors. The right one is a result when placing AddBorders right under ContinuityFixer prior to resize and results are the same for 720p which isn't pictured above.

The video also has 2 pixel artifact things prior to doing this (dunno what it is called) at the top and bottom thus the use of ContinuityFixer regardless something about this is wrong or I'm at fault.

Also, I've tried using my reliable Fill Margin as well (before finding out about ContinuityFixer) but that didn't work either.... And as usual when I don't use AddBorders and leave it cropped it's perfect but has no black border for that letterbox perspective. Ideally I want it at the end of the script and I don't want to change how I resize, is this possible? Is this normal?

I can't win regardless. Am I doing something wrong? Maybe it's something so small that I don't see why I'm having this problem. I've tried looking around but no topics on this or I just don't know how to search well maybe I'm doing something wrong. Any help please or send me to a filter that can fix this or doesn't do this nonsense. Sorry for the long post and spamming the word borders a lot. :(

[real.finder]

AddBorders should be always in the end of script because it may did these problems, also why still using the 16 lsb instead of HBD?

[dREV]

AddBorders should be always in the end of script because it may did these problems

:eek:

OK, putting it after Dither_out() worked super thanks! Something so simple that I didn't even consider at all. It was driving me nuts. :thanks: :goodpost:

It doesn't make sense why the Dither_addborders16 wasn't working though.

also why still using the 16 lsb instead of HBD?

https://forum.doom9.org/showthread.php?p=1884224#post1884224

[real.finder]

:eek:

OK, putting it after Dither_out() worked super thanks! Something so simple that I didn't even consider at all. It was driving me nuts. :thanks: :goodpost:

It doesn't make sense why the Dither_addborders16 wasn't working though.



https://forum.doom9.org/showthread.php?p=1884224#post1884224

if you add borders to the right or/and left it will not work again since you use it with hacked Dither_out clip, Dither_addborders16 should work with #trial 3 or as Dither_addborders16(0, 88, 0, 88).Dither_out() if it not broken, anyway that confusion you got from using lsb/dither hacks without know how things work :sly:

[dREV]

Hello again posting again to bother people with my mundane issues again. I ran into issues thinking the problem was resolved it was only for one format and not the other one.

My issue is with H264 itself as viewing it on avspmod it looks fine just the way I wanted it, however, when it's encoded into H264 the issue has gotten way worse. I've added the AddBorders() at the very very end of the script but I'm getting these results....

Examples:
Left: How it looks in H264
Right: Increased saturation to show the issue.

https://i.ibb.co/n6vdRFP/addborder-h264.jpg https://i.ibb.co/HgzF5dY/addborder-h264-saturation.jpg

My guess is that the issue maybe somehow the usage of H264 with the command line input of --input-depth 16 and using avs4x264mod.exe to pipe it for the lsb hack and maybe using the last version of kMod h264.

I cannot use the newer updated versions of H264 as I haven't figured out how to pipe lsb into it via command line without it stopping and giving me errors via MeGUI. On HEVC everything works out fine no issues even using the lsb hack and the avs4x264mod.exe (renamed to avs4x265.exe) to get it to work using 32 bit MeGUI version 2525.

I've asked how I can still use the hack using the newer H264 at MeGUI's 64 bit page but no reply at all. https://forum.doom9.org/showthread.php?p=1880471#post1880471

Can I get some help to get this AddBorders() to work properly on H264? As the resizer script (shown above in my first post) may help to the reason I'm having issues on this. :scared:

[hello_hello]

Maybe it'd help if the borders and/or the picture between them, were all mod16. I think blurry borders was more of a problem for Xvid than for x264, but try making each border and the picture height all evenly indivisibly by 16, or at least 8, to see if it helps.

Mind you, if you don't need to create an "industry standard" thing, for a Bluray or DVD compliant video disc etc, I've never understood the logic behind encoding borders, unless of coarse the picture resolution/aspect ratio changes, and you're adding them in places because of that.

[dREV]

Maybe it'd help if the borders and/or the picture between them, were all mod16. I think blurry borders was more of a problem for Xvid than for x264, but try making each border and the picture height all evenly indivisibly by 16, or at least 8, to see if it helps.

That seems excessive isn't? Making sure they all mod16. I've read that the older players needed the mod16 but nowadays it's not needed or mod2 is enough. Thanks for your time in replying as I did further testing since then and received these messages.

----[NoImage] Error message for your reference: AddBorders: YUV image can only add by Mod 2 (top).

Trying out basic Spline36Resize() and dither_resize16() both 848x480 and 852x480 even when it gave the error (above) I did 852x478 and still no good. This is even making certain that under MeGUI under H264 with the following Upsizing allowed MOD value used for resizing mod16 is selected as well but the result are still the same.


Mind you, if you don't need to create an "industry standard" thing, for a Bluray or DVD compliant video disc etc, I've never understood the logic behind encoding borders, unless of coarse the picture resolution/aspect ratio changes, and you're adding them in places because of that.

This is my first source in letterbox format so I'm new to this. I have other sources where sometimes for dynamic effect has letterbox and other stuff with just black border and I'm interesting in cutting that out and adding it back a clean border.

I'm about to give up on this and forget about this addborder thing for H264 since the entire purpose was to first get rid of the 2 pixel artifact that's on the source and fixing it with ContinuityFixer().

What I don't understand is why there's no issue in HEVC only H264.

[hello_hello]

The mod16 idea was just something to try, so each encoder block should be all border, or all picture, but not both. Why h265 is different, I'm not sure. Maybe it chooses block sizes differently.

It might be caused by the chroma upsampling. Are you encoding as YV12? You could encode without chroma subsampling to see what happens. I think YV24 is fine for x264, if MeGUI lets you.
http://avisynth.nl/index.php/YUV

In case you want to try, even though I doubt it's the cause, Resize8 (http://avisynth.nl/index.php/Resize8) corrects the Avisynth resizer chroma placement shift (https://forum.doom9.org/showthread.php?p=1506374#post1506374).

That's all my ideas at the moment.

[-QfG-]

Simply use:

AddBorders(0, 132, 0, 132, color_black)

at end of your script, for black letterboxes.

Also you can resize, before you set your AddBorder command. I do it so, if i encoding a 2160p video to a 1080p video.

Example :

begin of script
Crop(0,280,-0,-280) DAR=2.40:1
then...
resize 2160p to 1080p
tonemapping and other commands
end of script
AddBorders(0, 140, 0, 140, color_black) DAR=16:9

[dREV]

The mod16 idea was just something to try, so each encoder block should be all border, or all picture, but not both. Why h265 is different, I'm not sure. Maybe it chooses block sizes differently.

Ah I see.

It might be caused by the chroma upsampling. Are you encoding as YV12? You could encode without chroma subsampling to see what happens. I think YV24 is fine for x264, if MeGUI lets you.
http://avisynth.nl/index.php/YUV

In case you want to try, even though I doubt it's the cause, Resize8 (http://avisynth.nl/index.php/Resize8) corrects the Avisynth resizer chroma placement shift (https://forum.doom9.org/showthread.php?p=1506374#post1506374).

That's all my ideas at the moment.

I don't think it's caused by the upsampling since as I wrote in post 7 that I used basic Spline36() resizer in the 8 bit field and continued on with 16 bit filters after and still got the same results. I might be wrong but I believe it's under the YV24 when it uses the resizer I use at least according to MeGUI that's what it said to me, however, it did try to add in YV12 at the end of the script but I didn't allow it as I dunno what it's doing. However, I am doing this via 4:2:0 instead of 4:4:4. Could that play apart? I mean without this AddBorders() thing I've done several like this and plays just fine no issues at all with the video.

According to the documentation http://avisynth.nl/index.php/AddBorders I don't see YV24 there but it works fine on HEVC... This doesn't make sense to me. I don't understand why Dither_addborders16() (http://avisynth.nl/index.php/Dither_tools#Dither_addborders16) is not working as suppose to. Thanks for your time.


Simply use:
at end of your script, for black letterboxes.

Also you can resize, before you set your AddBorder command. I do it so, if i encoding a 2160p video to a 1080p video.

Example :

begin of script
Crop(0,280,-0,-280) DAR=2.40:1

then...
resize 2160p to 1080p
tonemapping and other commands

end of script

AddBorders(0, 140, 0, 140, color_black) DAR=16:9

But I did use it at the end of the script. Look at my first post above that's the script I am using, however, the only exception is the placement of AddBorders() which is now below Dither_out().

Aren't you using HEVC for your example? Since it seems you're using 4k resolution and I dunno if H264 can handle that size since I don't own any sources like that. Anyways, as I wrote there's no issues when doing this exact thing in HEVC this problem is only happening with H264. Thanks for your reply tho.

[hello_hello]

Edit: New post.

I'm starting to wonder if I've misunderstood the problem a bit.
I use MeGUI myself, but not for anything other than 8 bit encoding of 8 bit video. I'm not sure it's possible to use MeGUI to encode a stacked 16 bit output with x264, and I didn't try because I'm running XP, and as everything is 32 bit MeGUI sends the script directly to x264, and I don't think you can change any of that.

I did try three encodes though. The first used this script while encoding as 8 bit. Resized and cropped before DitherTools to make sure the edges were clean.

Trim(19876, 20313)
CropResize(728, 536)
Crop(20,20,-20,-20)
Dither_convert_8_to_16()
Dither_resize16(728, 536)
Dither_addborders16(20,20,20,20)
DitherPost()

For the second, I used the same script, but a 10 bit encode.

For the third, I used the instructions in the DitherTools help file, except MeGUI uses an x264 version for 8 and 10 bit encoding in a single exe (at least on XP). I managed to encode something with the command line below, after a bit of trial and error, because I'm hopeless with command line stuff (via a command prompt, not MeGUI). I used Avs2YUV from here (https://github.com/MasterNobody/avs2yuv/releases). I know nothing about avs4x264mod.exe and what it will and won't do, but there's 32 and 64 bit flavours of Avs2YUV. The script was the same as before, only it ended with Dither_out() rather than DitherPost().

"D:\avs2yuv.exe" -raw "D:\test.avs" -o - | "C:\Progra~1\MeGUI\tools\x264\x264.exe" --demuxer raw --input-depth 16 --input-res 768x576 --fps 23.976 --level 4.1 --output-depth 10 --preset slow --tune animation --crf 18.0 --output "D:\3.mkv" -

Do these look okay? The borders are deliberately not mod16 so they might not be razor sharp.
Don't worry about the picture quality. It was just something I had handy.

1.mkv (https://www.file-up.org/imcmrihxo7yt)
2.mkv (https://www.file-up.org/3lpwotvvrqtr)
3.mkv (https://www.file-up.org/ccq4ojvmqmry)

[-QfG-]

Aren't you using HEVC for your example? Since it seems you're using 4k resolution and I dunno if H264 can handle that size since I don't own any sources like that. Anyways, as I wrote there's no issues when doing this exact thing in HEVC this problem is only happening with H264. Thanks for your reply tho.

I crop always, no matter which resolution and addBorders at the end of the script. Without dither. I do this, because i have a little bit mor frames during encoding process. No one i have an error, likes your one.
My Avisynth Frontend ist StaxRip.

[qyot27]

How are you setting x264's macroblock partition settings? 4x4 for P-frames is not enabled by default, and there doesn't appear to be a 4x4 option for B-frames at all; ultrafast preset deactivates all the partition types, superfast only enables 8x8 and 4x4 on I-frames, the use of all types is only enabled starting at preset slower, and the 8x8 DCT gets deactivated on ultrafast and if you force Main profile.

You don't see this with HEVC because either the standard itself requires using all the types by default, or x265 does (and doesn't appear to have any options to tweak that behavior, unless that's what all the tu/cu/ctu sizing stuff is).

Basically, mod8 is likely safe to use no matter what configuration you're using, mod16 is even safer. With mod4 it's a roll of the dice.

[dREV]

Edit: New post.

I'm starting to wonder if I've misunderstood the problem a bit.
I use MeGUI myself, but not for anything other than 8 bit encoding of 8 bit video. I'm not sure it's possible to use MeGUI to encode a stacked 16 bit output with x264, and I didn't try because I'm running XP, and as everything is 32 bit MeGUI sends the script directly to x264, and I don't think you can change any of that.

I did try three encodes though. The first used this script while encoding as 8 bit. Resized and cropped before DitherTools to make sure the edges were clean.

Trim(19876, 20313)
CropResize(728, 536)
Crop(20,20,-20,-20)
Dither_convert_8_to_16()
Dither_resize16(728, 536)
Dither_addborders16(20,20,20,20)
DitherPost()

For the second, I used the same script, but a 10 bit encode.

If you saw my first post it's exactly as I put it with the exception of trial #4 as that AddBorders() is under Dither_out().

I've gone ahead and uploaded the MeGUI version I use for you 3 to see if you want. Maybe can figure out what I am doing wrong the MeGUI version is old 2525 and I included the avisynth plugins for both the original 2.0.6 version if that'll help and includes some plus plugins and for that version I am using 2772, so I don't be wasting your guys time and can see exactly what I got http://www.mediafire.com/file/3ike0cfubqlhxol/MeguiAndStuff.rar/file zipped in rar format using version 5.71. Not sure if hello_hello will be able to see if using Windows XP as I am on Windows 7 64 bit.

Sorry if the file is a bit large but is due to ffmpeg. I deleted some unnecessary files like hevc and 10 bit h264. Some MeGUI files uses updated stuff here and there, I don't think that'll cause any issues and if possible I like to keep using version 2525 due to my need of the .h264 format as I think the developer took this feature out on later versions as well as one of the DGI stuff that goes with it.

The avspipe comes from I believe here https://astrataro.wordpress.com/2014/08/28/avs4x26x-0-10-0/ not sure if there's an update to this
The kMod h264 came from here http://komisar.gin.by/

Basically the two above sentences I need in order to pipe fake 16 bit as I wrote before I am unable to do this on newer versions of h264 and I can't figure out why maybe has to do with ffmpeg (i think) has changed it to have both 8 bit and 10 bit within one which I guess is why kMod is no longer being updated. If any of you can provide me a link for me to look at and try out and continue using the fake 16 bit method I'd appreciate it as well. I also only exclusively use the One-Click mode too. I also like to note that I set MeGUI to not insert YV12] as it was asking me to do that since my resizer is using 4:4:4 equivalent (I think YV24) and I told it no. I don't see any issues with the video.


For the third, I used the instructions in the DitherTools help file, except MeGUI uses an x264 version for 8 and 10 bit encoding in a single exe (at least on XP). I managed to encode something with the command line below, after a bit of trial and error, because I'm hopeless with command line stuff (via a command prompt, not MeGUI). I used Avs2YUV from here (https://github.com/MasterNobody/avs2yuv/releases). I know nothing about avs4x264mod.exe and what it will and won't do, but there's 32 and 64 bit flavours of Avs2YUV. The script was the same as before, only it ended with Dither_out() rather than DitherPost().

Do these look okay? The borders are deliberately not mod16 so they might not be razor sharp.
Don't worry about the picture quality. It was just something I had handy.

1.mkv (https://www.file-up.org/imcmrihxo7yt)
2.mkv (https://www.file-up.org/3lpwotvvrqtr)
3.mkv (https://www.file-up.org/ccq4ojvmqmry)

Old version it was possible as I'm using it, supplied above. I use the same avs pipe for HEVC. Seems you using a newer version of MeGUI too which I'm not.

Well, I was looking for the razor sharp one but I think you also see you're getting the same results as I am even on the 10 bit version has it.

Based on your 1.mkv, (1st) left image zoomed in at at the bottom (maybe hard to see but you're getting the exact same results as I am 1 pixel deep, (2nd) center image I increased the same left image with saturated colors to see it more clearly, and the (3rd) right image comes from the sample I've been using in my previous posts that it AddBorders() worked on my HEVC encode but increased saturation color and as can see the results are clean not leaking to the main video. I'm trying to get this one to be the same on H264.

https://i.ibb.co/vL97XYs/hellos-addborder.jpg https://i.ibb.co/9cTWDyS/hellos-addborder-saturation.jpg https://i.ibb.co/0qhHFPz/addborder-hevc-saturation.jpg

I crop always, no matter which resolution and addBorders at the end of the script. Without dither. I do this, because i have a little bit mor frames during encoding process. No one i have an error, likes your one.
My Avisynth Frontend ist StaxRip.

Dither shouldn't be causing this at least I don't believe so and I've read here on doom9 itself that I should dither. If you grab my megui from mediafire you can see what I'm using if you don't mind.

How are you setting x264's macroblock partition settings? 4x4 for P-frames is not enabled by default, and there doesn't appear to be a 4x4 option for B-frames at all; ultrafast preset deactivates all the partition types, superfast only enables 8x8 and 4x4 on I-frames, the use of all types is only enabled starting at preset slower, and the 8x8 DCT gets deactivated on ultrafast and if you force Main profile.

You don't see this with HEVC because either the standard itself requires using all the types by default, or x265 does (and doesn't appear to have any options to tweak that behavior, unless that's what all the tu/cu/ctu sizing stuff is).

Basically, mod8 is likely safe to use no matter what configuration you're using, mod16 is even safer. With mod4 it's a roll of the dice.

I'm using all partitions, basically I am using max settings with --veryslow excluding vbr stuff. If you get my megui you can see exactly my settings.

On HEVC I'm almost using max settings too just have SAO off and I switch between --slower and --veryslow and using input-depth 16 with the same avspipe as mentioned above just renamed to avs4x265.exe. I think I included those settings in the link above too.

The preset I've been using throughout this is called "# UNIVERSAL 480p custom" under x264.

[StainlessS]

Could this be at related ?

Because of mpeg2 chroma placement, change in colorspace will sort of average two chroma samples [EDIT: or probably 4, 2x2] to ascertain destination color [I've never liked that much].

Here, 1st image without colorspace conversion, made jpeg from YV12, 2nd image from ConvertToYV24 (ConvertToRGB32 about same).


WH=16
A=BlankClip(Pixel_Type="YV12",width=WH,height=WH,Color_YUV=$AA48A0)
B=A.Invert
C=StackHorizontal(A,B)
D=StackHorizontal(B,A)
StackVertical(C,D)
trim(0,-1)
###

ConvertToYV24
#ConvertToRGB32

return PointResize(512,512) # for view


https://i.postimg.cc/hvVvWShM/test-00.jpg (https://postimages.org/)

https://i.postimg.cc/pd7Lm9Fq/test-01.jpg (https://postimages.org/)

EDIT: Horizontally, I see 3 different colors at crossover, vertically only 2. (???)

EDIT: And just to make it obvious where the join is

WH=16
A=BlankClip(Pixel_Type="YV12",width=WH,height=WH,Color_YUV=$AA48A0)
B=A.Invert
C=StackHorizontal(A,B)
D=StackHorizontal(B,A)
StackVertical(C,D)
trim(0,-1)
###

ConvertToYV24
#ConvertToRGB32

PointResize(512,512) # for view

# Chop em up
SEP=4
SEPCOL=$FF0000
TL=Crop(0,0,256,256)
TR=Crop(256,0,0,256)
V=TL.BlankClip(Width=SEP,color=SEPCOL)
TOP=StackHorizontal(TL,V,TR)
BL=Crop(0,256,256,0)
BR=Crop(256,256,0,0)
BOT=StackHorizontal(BL,V,BR)
HBAR=TOP.BlankClip(height=SEP,color=SEPCOL)
# Spit em out
return StackVertical(TOP,HBAR,BOT)

https://i.postimg.cc/Gt0mbzgb/test-02.jpg

[dREV]

stuff

I highly doubt it because I just did some further testing if it was present on other H264 using MeGUI 64 bit version 2896 and the issue is present even on H264 version 2935.0. This MeGUI 2896 is fresh none of my scripts present and just did a 8 bit quick script as follows:

Crop(0, 132, 0, -132)
Spline36Resize(852,362)
AddBorders(0, 58, 0, 58, color=041468)

To arrive at those results.

So the issue is either within H264 itself processing it or with the combination of AddBorders() seeing it works just fine on HEVC.

Thanks for the help and everybody else who tried to help.

[poisondeathray]

Post a sample of your source, and your log files for x264 and x265

Are you using 4:2:0 or something else for either ? Double check the log , or with mediainfo

[dREV]

Post a sample of your source, and your log files for x264 and x265

Are you using 4:2:0 or something else for either ? Double check the log , or with mediainfo

I am doing 4:2:0, 852x480.

There's no need to post a sample because I'm not the only one with this issue, please see post 11 by hello_hello (https://forum.doom9.org/showthread.php?p=1884958#post1884958) and the results found on his mkv samples with the same result as mine on post 14. So I'm certain anybody can replicate this and get the same results for themselves.

-------------------------------------------------

Pondering on what StainlessS posted I did several test samples using H264's 4:4:4 --profile high444 --input-depth 16 --sar 1:1 --output-csp i444 (forced a 10 bit from it too guess it's not like HEVC 8 bit 4:4:4) and the results turned out way better but has hard to see artifacts only present if saturated colors are done, can hardly tell but it's irrelevant if I can't do the same in 4:2:0.

This was due to adding

Dither_out() #result a
AddBorders()

However, switching to the 16 bit variant

Dither_addborders16() #result b
Dither_out()

improved it even further. And just for a quick test did HEVC 8 bit 4:2:0 (using only #result a script) and it produced almost the same annoying artifacts but without the annoying bar lines (see post #5 (https://forum.doom9.org/showthread.php?p=1884673#post1884673)) but when I switched to it's 4:4:4 variant using both #result script as mentioned previously they are both perfect.

So the only way to get this perfect is to use 4:4:4 in either H264 or HEVC... why?

I don't really know why this is occurring but seems StainlessS maybe onto something but I'm no expert as I don't understand the relation between chroma placement has to do with AddBorders(). I thought maybe even using basic filters like the Spline36() would of been fine as I thought maybe it was the filters too but seems it isn't.

I thought about using Letterbox() but then I remembered I need to crop first to use EdgeFixer... orz

[StainlessS]

Post your sample as requested by PDR (and full script), whether others have same problem or not dont really come into it,
we is tryin' to fix your problem, (or get the others with problem to post their source and scipt), PDR will be wantin' to
replicate your results and so see what is going wrong, he is not questioning whether the problem exists.
[It provides a better method for finding problem than just guessin']

[hello_hello]

Basically the two above sentences I need in order to pipe fake 16 bit as I wrote before I am unable to do this on newer versions of h264 and I can't figure out why maybe has to do with ffmpeg (i think) has changed it to have both 8 bit and 10 bit within one which I guess is why kMod is no longer being updated. If any of you can provide me a link for me to look at and try out and continue using the fake 16 bit method I'd appreciate it as well. I also only exclusively use the One-Click mode too. I also like to note that I set MeGUI to not insert YV12] as it was asking me to do that since my resizer is using 4:4:4 equivalent (I think YV24) and I told it no. I don't see any issues with the video.

I copied the command line MeGUI was using and modified it, but it'll be different for your PC so I'd only be guessing.

Well, I was looking for the razor sharp one but I think you also see you're getting the same results as I am even on the 10 bit version has it.

I wasn't sure if it was really blurry or I'd over-indulged in fun things, but I deliberately made the borders non-mod16 so I'd expect a little bit of blur. I'll run the encoded again over the week-end with mod16 borders to see if anything changes.

I'm downloading your file. I'll report back over/after the weekend.

[poisondeathray]

So the only way to get this perfect is to use 4:4:4 in either H264 or HEVC... why?



It has to do with chroma subsampling . 4:4:4 means no subsampling. 4:2:0 means the chroma planes are halved in width and height, so the colors are going to bleed around edges. For you that's 426x240 worth of color information . How can you expect 426x240 to be "stretched" or spread pixel perfect to 852x480 ? You can't, and the result is what you see. Defects just get enhanced farther when you use lossy encoding .

When you "view" something it gets converted to RGB. Typically bilinear or bicubic is used for the chroma upsampling back to RGB for display. If bicubic (e.g. default in avisynth , avspmod), then a 4x4 pixel area grid is used for interpolation, hence the "contamination" of adjacent pixels. The Cb=128,Cr=128 (or U=128,v=128) color information of the "black" Y16,Cb128,Cr128 will appear to mix and affect the bordering edge pixels because of interpolation used. The Y channel is full resolution, no problem there . 4:4:4 would mean full resolution for Y,Cb,Cr, so no interpolation either. 4:2:2 would be 1/2 width color , but full resolution color height so you'd expect problems with horizontal edges.

Different algorithms will have various pros/cons. But there just is no way to get pixel perfect with 1/2 width, 1/2 height color - it's impossible

The reason your HEVC test looked ok was because it wasn't using 4:2:0, it was actually using 4:4:4

In your image editor, when you overlaid black borders, you were working in RGB - full color. No interpolation

[dREV]

Post your sample as requested by PDR (and full script), whether others have same problem or not dont really come into it,
we is tryin' to fix your problem, (or get the others with problem to post their source and scipt), PDR will be wantin' to
replicate your results and so see what is going wrong, he is not questioning whether the problem exists.
[It provides a better method for finding problem than just guessin']

My script has been posted for days now, see post #14 (https://forum.doom9.org/showthread.php?p=1885023#post1885023) is almost exactly like my first post (wondering if some of you are even reading my posts correctly that and I've posted alternative scripts also that can be replicated) and I can post the log file but I dunno how to do that. You mean MeGUI's processing stuff? I'm not sure if that's what you guys talking about but what's that gonna do?

I don't see the point in posting a sample because as hello_hello has confirmed I am not the only one receiving this issue and if others don't mind to report back receiving the same results. It only takes less than 5 minutes. Further, one can use their own video doesn't matter what it is since the purpose is to crop it and add the border and see if the 1-2 pixel smudge is present just as I did for hello_hello's example. I've also given many images of my sample results, how thorough does one have to be?

As mentioned before I'm not the only one that has got this issue. This issue could be wide spread since the birth of this filter with 4:2:0 and nobody as far as I know has written about this to inform.

I copied the command line MeGUI was using and modified it, but it'll be different for your PC so I'd only be guessing.

That's ok with me I might be able to figure out what you did and with search as long as you can let me know how to pipe a fake 16 bit with the newer H264 if you don't mind.

I wasn't sure if it was really blurry or I'd over-indulged in fun things, but I deliberately made the borders non-mod16 so I'd expect a little bit of blur. I'll run the encoded again over the week-end with mod16 borders to see if anything changes.

I'm downloading your file. I'll report back over/after the weekend.

That's the thing though, my samples were also in Mod16 at least under that MeGUI it was triggered to be on (unless it's broken because the option of choosing the alternative AviSynth instead of the one that's included is not working as intended) plus I've also did Mod2 (resolution (852x478) as well when I was using basic 8 bit filters so it wouldn't complain to me and still got the results I've outlined. I'm almost certain that you will end up getting the same results as I.

Thanks for your help and your time hello_hello.

It has to do with chroma subsampling . 4:4:4 means no subsampling. 4:2:0 means the chroma planes are halved in width and height, so the colors are going to bleed around edges. For you that's 426x240 worth of color information . How can you expect 426x240 to be "stretched" or spread pixel perfect to 852x480 ? You can't, and the result is what you see. Defects just get enhanced farther when you use lossy encoding .

When you "view" something it gets converted to RGB. Typically bilinear or bicubic is used for the chroma upsampling back to RGB for display. If bicubic (e.g. default in avisynth , avspmod), then a 4x4 pixel area grid is used for interpolation, hence the "contamination" of adjacent pixels. The Cb=128,Cr=128 (or U=128,v=128) color information of the "black" Y16,Cb128,Cr128 will appear to mix and affect the bordering edge pixels because of interpolation used. The Y channel is full resolution, no problem there . 4:4:4 would mean full resolution for Y,Cb,Cr, so no interpolation either. 4:2:2 would be 1/2 width color , but full resolution color height so you'd expect problems with horizontal edges.

Different algorithms will have various pros/cons. But there just is no way to get pixel perfect with 1/2 width, 1/2 height color - it's impossible

The reason your HEVC test looked ok was because it wasn't using 4:2:0, it was actually using 4:4:4

In your image editor, when you overlaid black borders, you were working in RGB - full color. No interpolation

OK, thanks for the explanation basically without 4:4:4 I can't get it perfectly. I assumed that the black border simply adds what would just be similarly as the image program layering the color to the video since it's one solid color. In my head I thought it was force cutting the video leaving like a slab of a virtual block left and then filling it with 2 solid black colored blocks within the resolution and joining them as one.

I'm not understanding your first paragraph, I understand the part of "halve" due to being 4:2:0 but the portion of "426x240" for the chroma I don't understand?

I made a post here which nobody has answered still (and a thread you made a post at as well) https://forum.doom9.org/showthread.php?p=1882463#post1882463 are you saying that the chroma was resized despite the script I referenced according to the first page of that thread and another one not there but was used in post #1 here for my 720p example https://forum.doom9.org/showthread.php?p=1884083#post1884083 saying otherwise?

Did I screw up? I don't want to them resized which is why I am using those resizers or is it cuz I went 4:2:0 for my 480p video? Maybe something I'm not understanding again.