ImageBorders & FrostyBorders Scripts

[avhp]

Thanks for the fix, it works fine now.

[hello_hello]

There's a new version of FrostyBorders dated 2024-11-16 in the opening post. It fixes the bug for the VapourSynth version discussed in post #150 as well as a couple of other obscure bugs for both versions. The way a border color is specified for the VapourSynth version has also been simplified. Details in the "Changes" text file.

Edit: For anyone using the FrostyBorders function included with CropResize, I'll update it to match the changes to the standalone FrostyBorders function in the near future.

[rgr]

Edit: Actually, the post is no longer valid -- now I've read that CropResize has such a option


Is it possible to "produce" a 1920x1080 PAR 1:1 frame using FrostyBorders (regardless of the input frame size and its PAR)?

That is:
1. The input frame is 1920x1080 (or 3840x2160) PAR 1:1 - Frosty does not change anything or only scales it
2. The input frame is 720x576 PAR 12:11 -- Frosty creates a 1920x1080 frame with borders?

Simply put, can this replace CropResize?

[rgr]

Ouch...

[avisynth @ 0000023834ba8600] CropResize
RGB is not supported for FrostyBorders

[hello_hello]

FrostyBorders doesn't support RGB because the Avisynth TemporalSoften function doesn't support RGB. The Avisynth+ TemporalSoften function fully supports planar RGB, but it's scene change detection can't be enabled for interleaved RGB (RGB32 and RGB64). Tweak is also used to adjust the brightness and saturation of the borders but it only supports YUV (same for VapourSynth), and I don't think the Avisynth FastBlur plugin supports planar RGB (only interleaved). So... I'm not sure it'd be possible to support RGB properly, or whether it'd be worth the effort even if those obstacles could be over-come.

Is it possible to "produce" a 1920x1080 PAR 1:1 frame using FrostyBorders (regardless of the input frame size and its PAR)?

Yes, for a 720x576 PAR 12:11 source:
FrostyBorders(1920,1080, InSAR=12.0/11.0)
or
FrostyBorders(1920,1080, InDAR=20.0/11.0)

20:11 is the mpeg4 equivalent DAR for 16:9 DVDs.
15:11 is the mpeg4 DAR for 4:3 DVDs.
They're easier to remember than two mpeg4 SARs for NTSC and another two for PAL, at least for me....

If you want to ensure the function is resizing without adding borders you can, by only specifying an output width or height rather than both. The video should still be resized correctly when an input DAR or SAR is used.

FrostyBorders(1920,0)
or
FrostyBorders(0,720) etc.

Simply put, can this replace CropResize?

It can much of the time, but CropResize has more functionality.
There's a function included with CropResize for creating global variables to configure the included CropResize/FrostyBorders function.
For example, these would produce the same output with the same borders.

FrostyBorders(1280,720, Clone=3, BDivider=2)
or
FrostyB(Clone=3, BDivider=2)
CropResize(1280,720, Frosty=true)

FrostyBorders can only resize and add borders if necessary for the specified width and height. By default, CropResize crops the picture to match the output aspect ratio (dimensions) before resizing, unless borders are enabled or an OutDAR or OutSAR is specified, or unless you use zero for either the width or height.

CropResize(960,720) would crop the source video to 4:3 automatically if necessary.
CropResize(960,720, Borders=true) would resize and add borders instead (as FrostyBorders does).

FrostyBorders can only resize to "square pixel" dimensions (a SAR of 1:1) and it doesn't include any cropping previews.

I'm currently trying to make CropResize more clever in respect to chroma placement, which has turned into a bit of a chore if it's color converting (and the video is converted to RGB and back), although both functions can be used with a chroma placement aware resizer.

Using the chroma location in frame properties.
FrostyBorders(1280,720, Resizer="Resize8", RStr=""" kernel="Spline64" """)
FrostyBorders(1280,720, Resizer="z_ConvertFormat", RStr=""" resample_filter="Spline64", use_props=1 """)

Specifying a "top_left" chroma location and shifting it to "left".
FrostyBorders(1280,720, Resizer="Resize8", RStr=""" kernel="Spline64", CPlace="top_left", CPlaceD="left" """)
FrostyBorders(1280,720, Resizer="z_ConvertFormat", RStr=""" resample_filter="Spline64", chromaloc_op="top_left=>left" """)

[Pab_]

Got FrostyBorders setup and working mostly well in MPC-HC64 on Windows 10. However, there's an intermittent problem that I haven't been able to solve, nor can I see any posts related to it in this thread.

What's happening is sometimes there will be a single-frame flash of blocky colour down the sides where the borders are rendered. It reoccurs between a few seconds and a few minutes apart each time, regardless of video source. I'd say on average it's probably one flash every minute or so, but it can be more frequent.

ffdshow settings match those shown in the instructional post, as per screenshot below. I've also added a few screengrabs showing the flashes (taken from a video capture).


[Attachment 84009 - Click to enlarge]


[Attachment 84007 - Click to enlarge]


[Attachment 84008 - Click to enlarge]

One last thing - I'm using FrostyBorders 2023-10-28. I haven't been able to test 2024-11-16 because MPC-HC crashes (just disappears) a few seconds after attempting to load it into ffdshow.

[hello_hello]

I've seen that sort of intermediate flash of blocky color very occasionally (usually red I think) but I've been running Avisynth Plus in Wine on Linux so I attributed it to some sort of Wine oddity as I don't think I've seen it happen when I've been testing on Windows 11 in VirtualBox. It shouldn't be ffdshow related as I don't have ffdshow installed in Wine so I've been testing by opening a script directly with AvsPmod.

Could you try opening a script directly with MPC-HC to see what happens when using the new version. Just create an Avisynth script to open the video and adding something like FrostyBorders(1280,720, CropDAR=4.0/3.0) should do.

The culprit is probably a plugin, and the only one used for the standard FrostyBorders is FastBlur (from memory), along with Avisynth's TemporalSoften. I'll do some experimenting as soon as I can (hopefully tomorrow) to see if I can find the cause.

[Pab_]

Thanks for getting back to me. I have now managed to update to the newest version, at least. Nothing to report there, it was a failure on my part to remember how to install it correctly. So I can now confirm that the flashes still happen in the newest version.

If there's anything I can change/test to narrow down the culprit let me know.

[hello_hello]

Out of curiosity, are you using an AMD CPU? I had a problem with another plugin recently that I think was related to the AVX instruction set in combination with my 7900X CPU and it appeared it was only an issue when running on Linux. The author fixed it but I'm curious if it might be CPU related as I hadn't seen it happen while I was using my old quad core Intel CPU.

I'm pretty sure the culprit is the FastBlur plugin. I think I've solved the problem but the trouble is it happens so intermittently there was quite a few times it didn't appear until the script had been running for 5 or 10 minutes and I was becoming confident the problem was fixed. By default, the FastBlur plugin uses internal multi-threading and the number of threads it uses is half the number of logical CPU cores, which may be too many considering the width of the clip cropped for the frosty borders is very narrow (it's then blurred and stretched to the correct width). That's just a guess, but limiting FastBlur to a single thread seems to have cured the problem so far. On my CPU it's still plenty fast enough to add borders to a 1440x1080 video in real time. For the other types of borders it's limited to 4 threads, although I haven't seen the problem occur with any other borders.

Anyway, if you'd care to test the attached version, please let me know how you go. I also modified the older version of the function before I read your post and discovered you'd managed to get the new version to work, so both versions are attached. If the problem hasn't gone away I'll have another look at it. There's a couple of other blurring plugins I could try but it probably won't be as simple as swapping one of them for FastBlur and still have the same output, and I probably won't have any time to play with it again until the weekend.

Cheers.

[Pab_]

I am indeed running an AMD CPU (Ryzen 7 5700G). Furthermore, just before your last post I installed and tested Frostyborders on my old PC (Intel Core i5 2500K) and tested 15m+ of video without any glitches, which is far longer than had ever been managed on my main system.

Moving on to the modded version you posted, I've tested the 2024-11-16 version on my main (AMD) system and can confirm a huge improvement. Watched a 47m video and only noticed a single flash the entire time, a white(?) one at ~16m. So the changes you made have made a big difference.

As I understand it FastBlur hasn't been updated for over 3 years so I'm guessing there's not much chance of improvement there. Regardless, thanks for making this modified version, it's much appreciated.

[hello_hello]

I'm glad that's an improvement. Let me know if the problem does re-occur at all. I can let the FastBlur author know to see if he's interested in taking a look, or see if there's another blurring plugin that'll do the same job, but it'll probably be a little while before I get a chance.

[Pab_]

Watched another 45m with the modded version last night and observed just two flashes. This is still a great improvement on the regular version.

I believe I've now found a way to test for flashes better - increased number of iterations. With Iterations=150, the regular 2024-11-16 version goes into flashing overdrive on my AMD system - I estimate them to be more than one per second on average. Conversely, with the modded version and the same number of iterations I didn't notice any flashes in ~4m of playtime.

This seems to confirm you were right about it being related to FastBlur and the number of threads.

[hello_hello]

Thanks for the testing.
I tried increasing the number of iterations originally but it didn't seem to make a difference when I was testing the script in AvsPmod, however I have discovered the flashing happens more often when opening the script in MPC-HC, and also when encoding the output. I don't know why. Maybe using three instances of FastBlur chained together with a single iteration for each might be the answer. I'm not sure how different it'd look as I haven't tried that yet.

I've reported the problem to the FastBlur author but I haven't had time to play around a lot more. If you do feel like experimenting more yourself, maybe try creating a script like this and opening it in MPC-HC. It's a simulation of how the function uses FastBlur to create a border for a 720p source, and the more instances you stack together, the more likely you'll see flashes, so you shouldn't have to wait too long to see if a setting change has made a difference. I'm pretty sure the blurring values FrostyBorders uses for pillarbox borders are the width of the clip cropped for the borders (32 in this case, but the cropping and blurring increases/decreases in proportion to the source resolution) and the height of the cropped clip divided by ten (72 for a 1280x720 source).

#some 720p source video
A = Crop(width()-32,0,0,0).FastBlur(32,72, 3, true, threads=undefined()).GaussResize(120,720)
B = Crop(width()-32,0,0,0).FastBlur(32,72, 3, true, threads=undefined()).GaussResize(120,720)
C = Crop(width()-32,0,0,0).FastBlur(32,72, 3, true, threads=undefined()).GaussResize(120,720)
D = Crop(width()-32,0,0,0).FastBlur(32,72, 3, true, threads=undefined()).GaussResize(120,720)
StackHorizontal(A, B, C, D)

[hello_hello]

Pab_,
If you're still around it looks like there's a blurring function I can substitute for FastBlur.
It's one of Dogway's functions. https://github.com/Dogway/Avisynth-Scripts/blob/master/ExTools.avsi
He has several blurring functions but so far BoxBlur looks promising, although like the VapourSynth BoxBlur it blurs sub-sampled chroma by the same amount as the luma, so to simulate what FastBlur does I'll have to separate them, blur and combine them again, but if you'd care to give this script a test run for any blocky flashing from ex_BoxBlur.... so far it's okay for me.
I think most of Dogway's functions require at least Avisynth Plus 3.7.1. GradFun3Plus is also one if his. I added it to see if it'd help prevent banding.
The output isn't exactly the same yet, but it's close. I think the difference relates to gamma somehow, but I'll have to play around a bit more when I get another chance.

# Some 720p source

Cropped = Crop(width()-32,0,0,0)

A = Cropped.FastBlur(32,72,3, true).GaussResize(120,720)

B = Cropped.ExtractY().ex_BoxBlur(32-1,72).ex_BoxBlur(32-1,72).ex_BoxBlur(32-1,72)
C = Cropped.ExtractU().ex_BoxBlur(16-1,36).ex_BoxBlur(16-1,36).ex_BoxBlur(16-1,36)
D = Cropped.ExtractV().ex_BoxBlur(16-1,36).ex_BoxBlur(16-1,36).ex_BoxBlur(16-1,36)
E = CombinePlanes(B,C,D, "YUV", pixel_type="YUV420P8").GaussResize(120,720).ConvertBits(16).GradFun3Plus().ConvertBits(8, dither=0)

StackHorizontal(A.Subtitle("FastBlur", align=5), E.Subtitle("ex_BoxBlur", align=5))

[Attachment 84150 - Click to enlarge]

[Pab_]

#some 720p source video
A = Crop(width()-32,0,0,0).FastBlur(32,72, 3, true, threads=undefined()).GaussResize(120,720)
B = Crop(width()-32,0,0,0).FastBlur(32,72, 3, true, threads=undefined()).GaussResize(120,720)
C = Crop(width()-32,0,0,0).FastBlur(32,72, 3, true, threads=undefined()).GaussResize(120,720)
D = Crop(width()-32,0,0,0).FastBlur(32,72, 3, true, threads=undefined()).GaussResize(120,720)
StackHorizontal(A, B, C, D)

Thanks for the script, that helps test things. Number of iterations definitely makes a big difference on my system with multithreading on. With the default 3 iterations, I see a flash maybe every 20 seconds or so. With iterations increased to 100, they are much more frequent. Attached video shows the latter.

mpc-hc64_241215-144339.mp4

I have also tried it with 100 iterations and threads set to 1 and haven't noticed any flashing. So again, single thread seems to fix the problem.

Just as I was about to hit send on this I got notified of your new reply, what a coincidence! I'll check it out later and get back to you.

[hello_hello]

I'm pretty sure I've still seen the occasional flash with threads=1, but maybe I confused myself somewhere along the way.

Edit: I just watched your video. It's odd because today I've barely seen a flash from FastBlur, whereas a couple of days ago it was going mental. If you're sure threads=1 is definitely a fix I'll leave FastBlur as the plugin. It'll save me some work trying to swap them out.
None of the testing I've done has been with Avisynth's multi-threading enabled (no Prefetch in the script), as I think for me enabling multi-threading actually slowed things down when running the function via ffdshow. It was a fair while ago though, so I could be remembering wrong.

[thebib62]

Came here to say that i have been experiencing the same issue for a while... thought it was just me. hoping it can be looked into.

clip = last
W = width(clip)
H = height(clip)
# If the source is anamorphic the correct pixel/sample aspect ratio must
# be specified instead of 1.0. For example, 64.0/45.0 for a PAL 16:9 DVD.
# The SAR must be float (not integer).
SAR = 1.0
# When CropDAR is any negative number, the CropDAR is automatically calculated and applied.
# When CropDAR = 0 it's permanently disabled.
# When CropDAR is greater than zero it's the CropDAR that's always applied.
# If CropDAR is greater than zero it must be float (4.0/3.0 or 1.3333 etc).
CropDAR = 0
# Cropping.  CR and CB must be negative (or zero).
CL = 2
CT = 2
CR = -2
CB = -2
VideoDAR = float(W - CL + CR) / float(H - CT + CB) * SAR
CropDAR = (CropDAR >= 0) ? CropDAR : \
(VideoDAR > (16.0/9.0)) ? 16.0/9.0 : \
(VideoDAR > (14.0/9.0)) ? 14.0/9.0 : \
(VideoDAR > (7.0/5.0)) ? 7.0/5.0 : 4.0/3.0
return (VideoDAR == (4.0/3.0)) && (SAR == 1.0) ? clip : \
FrostyBorders(640,480, CL,CT,CR,CB, InSAR=SAR, CropDAR=1.7, TCRatio=0.3,bright=0, cont=1.0, sat=0.85)

would you be able to help incorporate the threads=1 value to my current script?

[Pab_]

If you're sure threads=1 is definitely a fix I'll leave FastBlur as the plugin. It'll save me some work trying to swap them out.

That does seem to be the case on my system and if it's not perfect, it's close enough. I've noticed only 3 flashes in 3 hours of playback using the modded version you posted. That's plenty good enough for me, at least. As well as the extra work the The ex_BoxBlur alternative you posted also has the disadvantage of lots of prerequisites - think I had to install 6(?) additional scripts/plugins to get it to work.

Thanks again for your help, and thanks for FrostyBorders. It's exactly what I was looking for to make me feel better about watching hundreds of hours of 4:3 content on an OLED TV. I know modern sets are much improved in this regard, but those inert pixels were still making me anxious. Plus it just looks really good!

[hello_hello]

would you be able to help incorporate the threads=1 value to my current script?

Hi.
It's set to threads=1 for the modded version of FrostyBorders attached to post #159. Just replace FrostyBorders with the modded one. The script you're using doesn't have to change.
Edit: The Clone borders are using threads=4 for the modded version because I haven't seen any flashes with those borders, so I didn't reduce threads as much, but if you use them and you still see flashes I can change it to threads=1 for those borders too.

Pab_,
Yeah, a lot of Dogway's functions rely on several of his other functions. Mind you he's created some pretty cool functions so it can't hurt to have them. If you use QTGMC, his version is a bit faster than the standard one and I think the quality is a (tiny) bit better.
Unfortunately I haven't been able to find another blurring plugin similar to FastBlur. What I might do at some stage if I can, depending how many there are, is copy the required Dogway functions into the FrostyBorders script itself so it won't have any more external dependencies, and I'll add an argument to FrostyBorders to make it easy to choose between FastBlur and the blurring function. That's the plan, hopefully sometime soon....

Cheers.

[Pab_]

Sounds good. Happy to test any future developments.

[hello_hello]

I ended up with an hour or so to kill this morning so I couldn't help myself.
The default is still FastBlur, but this will switch to ex_BoxBlur. There's no additional dependencies now, they're included. I didn't include Gradfun3 as the borders are converted to 16 bit for blurring and then dithered back to the original bitdepth.

FrostyBorders(1280,720, CropDAR=4.0/3.0, Blurring="BoxBlur")

I still need to add some checks and I want to see if I can adjust the gamma a little, but in the mean time if you'd like to take this version for a spin, let me know if anything silly happens. I assume you're using it already, but Blurring="BoxBlur" needs Avisynth Plus 3.7.3, according to Dogway's ExTools requirements.

Edit: Enabling feathering will probably result in an error at the moment. There's a cryptic error message regarding the maximum blurring I thought I'd worked around, but it'll probably pop-up if feathering is enabled until I can fix that, so make sure Feather=0 (the default).
Also the Iterations argument doesn't apply to "BoxBlur".

[Pab_]

Nice job, it seems to be working.

Can confirm that there's an error message with BoxBlur+feathering, which is probably a good indicator that it's actually using BoxBlur.

Output compared to FastBlur seems a really close match from taking a few screengrabs of the same frame with both options. The only obvious difference I can see is in CPU usage - with FastBlur MPC-HC sits at ~2%, with BoxBlur it's ~6%. Not a big deal, just seemed noteworthy.

[hello_hello]

Pab_,

I'm almost going to be a bit annoyed if this works as I'd just spent a bit of time getting ex_BoxBlur to play nice with feathering enabled, and I still have one problem to solve, but it occurred to me I hadn't tried testing with FastBlur's dithering disabled, so I gave it a try, and combined with threads=1 it might be the solution.

The attached script only uses FastBlur. To make up for it's dithering being disabled, the borders are created like this, so it'll probably increase CPU usage by one or two percent, but it shouldn't be much more than that.

Crop(width()-32,0,0,0).ConvertBits(16).FastBlur(32,72,3).Conver tBits(Source_Bits, dither=1).GaussResize(120,720)

This version has an argument named Threads. The default is Threads=1.
If you'd care to give it a test drive to see how it goes for you, that'd be great.

Cheers.

[thebib62]

Now that the flashing issue has seemingly been addressed, would you be able to update both of my all-in-one scripts that you made for me previously? I want it to incorporate the threads=1 & box blur arguments.

The first script is for my tablet that's more closer to a 4x3 aspect ratio and the second script would be to accommodate a 16x9 aspect ratio and if you don't mind, would you be able to make one for my ultra wide 21x9 aspect ratio monitor?

clip = last
W = width(clip)
H = height(clip)
# If the source is anamorphic the correct pixel/sample aspect ratio must
# be specified instead of 1.0. For example, 64.0/45.0 for a PAL 16:9 DVD.
# The SAR must be float (not integer).
SAR = 1.0
# When CropDAR is any negative number, the CropDAR is automatically calculated and applied.
# When CropDAR = 0 it's permanently disabled.
# When CropDAR is greater than zero it's the CropDAR that's always applied.
# If CropDAR is greater than zero it must be float (4.0/3.0 or 1.3333 etc).
CropDAR = 0
# Cropping.  CR and CB must be negative (or zero).
CL = 2
CT = 2
CR = -2
CB = -2
VideoDAR = float(W - CL + CR) / float(H - CT + CB) * SAR
CropDAR = (CropDAR >= 0) ? CropDAR : \
(VideoDAR > (16.0/9.0)) ? 16.0/9.0 : \
(VideoDAR > (14.0/9.0)) ? 14.0/9.0 : \
(VideoDAR > (7.0/5.0)) ? 7.0/5.0 : 4.0/3.0
return (VideoDAR == (4.0/3.0)) && (SAR == 1.0) ? clip : \
FrostyBorders(640,480, CL,CT,CR,CB, InSAR=SAR, CropDAR=1.7, TCRatio=0.3,bright=0, cont=1.0, sat=0.85)

[Pab_]

The attached script only uses FastBlur. To make up for it's dithering being disabled, the borders are created like this, so it'll probably increase CPU usage by one or two percent, but it shouldn't be much more than that.

Crop(width()-32,0,0,0).ConvertBits(16).FastBlur(32,72,3).Conver tBits(Source_Bits, dither=1).GaussResize(120,720)

This version has an argument named Threads. The default is Threads=1.
If you'd care to give it a test drive to see how it goes for you, that'd be great.

Honestly, the flashing is already so rare now with a single thread that it's getting difficult to test. I've been back-and-forth between 2024-12-16 and 2024-12-19 I'm not seeing any obvious difference so far.

One time in the latest test version I had an obvious blue flash on one side within a few seconds of playback starting, even with default iterations. However the rest of the time I haven't seen any flashes even with Iterations=100 so I think this was just an unlucky rare flash like I have also seen with the previous version (which usually occur maybe once every few hours at default settings).

Finally, there was no noticeable difference in CPU usage between the last two versions on my system - both sit around 2.5% with default iterations.

[hello_hello]

Pab_,
I had the last test version running for about 90 minutes yesterday and didn't see any flashes, so I thought they were gone, but hopefully if it hasn't cured the problem they'll be quite rare now.

The attached scripts should be the final versions. There's two, as the one that includes BoxBlur won't play nice with older versions of Avisynth. Chances are if you put it in the plugins folder to auto-load, it'll prevent any version of Avisynth prior to AviSynth Plus 3.7.1 from running at all, as the script contains square brackets and earlier versions of Avisynth will produce an "unrecognized character" error. Using BoxBlur requires Avisynth Plus 3.7.3 anyway.

The function named "FrostyBorders 2024-12-20.avsi" should even work with Avisynth 2.6, although I haven't tested it, and borders won't be dithered unless Avisynth Plus is used. As with the previous test version it has a Threads argument and the default is Threads=1.

The function named "FrostyBorders (With BoxBlur) 2024-12-20.avsi" requires Avisynth Plus 3.7.3 and has the same threads argument. Once again the default is Threads=1. It uses FastBlur by default too so the default output for both scripts should be the same.
I replaced the Blurring argument with one named BPlugin (so it'll work the same way as the existing GPlugin argument for specifying the grain plugin).

BPlugin = 0 Disables blurring completely.
BPlugin = 1 Selects FastBlur for blurring (it's the default).
BPlugin = 2 Selects BoxBlur for blurring.

Once again the Iterations and Threads arguments only apply to FastBlur.
I discovered I'd broken feathering for a couple of the Clone borders at some stage, so that's fixed.

thebib62,
To use the Threads & BPlugin arguments, just add them to the final line in your script and replace the version of FrostyBorders you're using with one of the attached versions. The FastBlur help file will tell you what the choices are (for instance Threads=0.75 uses threads equivalent to 75% of the number of CPU cores, or something like that, but Threads=1 is the best choice for an AMD CPU). Only add the BPlugin argument if you use the version with BoxBlur though, as the other one doesn't have a BPlugin argument so it'll produce an error.

FrostyBorders(640,480, CL,CT,CR,CB, InSAR=SAR, CropDAR=1.7, TCRatio=0.3,bright=0, cont=1.0, sat=0.85, Threads=1, BPlugin=2)

What sort of video do you normally watch on your widescreen monitor and what's the largest you want the borders to be?
I'll have to think about that one tomorrow anyway though, as I'm out of time today.

Cheers.

[thebib62]

Pab_,
I had the last test version running for about 90 minutes yesterday and didn't see any flashes, so I thought they were gone, but hopefully if it hasn't cured the problem they'll be quite rare now.

The attached scripts should be the final versions. There's two, as the one that includes BoxBlur won't play nice with older versions of Avisynth. Chances are if you put it in the plugins folder to auto-load, it'll prevent any version of Avisynth prior to AviSynth Plus 3.7.1 from running at all, as the script contains square brackets and earlier versions of Avisynth will produce an "unrecognized character" error. Using BoxBlur requires Avisynth Plus 3.7.3 anyway.

The function named "FrostyBorders 2024-12-20.avsi" should even work with Avisynth 2.6, although I haven't tested it, and borders won't be dithered unless Avisynth Plus is used. As with the previous test version it has a Threads argument and the default is Threads=1.

The function named "FrostyBorders (With BoxBlur) 2024-12-20.avsi" requires Avisynth Plus 3.7.3 and has the same threads argument. Once again the default is Threads=1. It uses FastBlur by default too so the default output for both scripts should be the same.
I replaced the Blurring argument with one named BPlugin (so it'll work the same way as the existing GPlugin argument for specifying the grain plugin).

BPlugin = 0 Disables blurring completely.
BPlugin = 1 Selects FastBlur for blurring (it's the default).
BPlugin = 2 Selects BoxBlur for blurring.

Once again the Iterations and Threads arguments only apply to FastBlur.
I discovered I'd broken feathering for a couple of the Clone borders in the latest version (the one in the opening post), so that's fixed.

thebib62,
To use the Threads & BPlugin arguments, just add them to the final line in your script and replace the version of FrostyBorders you're using with one of the attached versions. The FastBlur help file will tell you what the choices are (for instance Threads=0.75 uses threads equivalent to 75% of the number of CPU cores, or something like that, but Threads=1 is the best choice for an AMD CPU). Only add the BPlugin argument if you use the version with BoxBlur though, as the other one doesn't have a BPlugin argument so it'll produce an error.

FrostyBorders(640,480, CL,CT,CR,CB, InSAR=SAR, CropDAR=1.7, TCRatio=0.3,bright=0, cont=1.0, sat=0.85, Threads=1, BPlugin=2)

What sort of video do you normally watch on your widescreen monitor and what's the largest you want the borders to be?
I'll have to think about that one tomorrow anyway though, as I'm out of time today.

Cheers.

I normally watch 4:3 or 16:9 videos on all my deceives.

Also, I keep getting an error when trying to use those 2 new scripts.
"ConvertBits: YUY2 input must stay in 8 bits. (PillarBox Frosty Eval, line 51)"

[hello_hello]

Pab_,
The versions attached to this post require a change to the ffdshow script in the second post. I fixed the check that CropDAR is specified as float. It means when a CropDAR of zero is specified (the same as an undefined CropDAR) it must also be float. So for this line....

CropDAR = (VideoDAR > 2.0) ? 2.0 : (VideoDAR > (14.0 / 9.0)) ? 0.0 : (VideoDAR > 1.3) ? 14.0 / 9.0 : 7.0 / 5.0

thebib62,
I didn't know YUY2 was still a thing....

The error is because the script converts the borders to 16 bit and back for blurring, and YUY2 can only be 8 bit.
You can fix it by adding ConvertToYV16() to the script prior to FrostyBorders, or if YUY2 is selected as an input color space in ffdshow's Avisynth filter configuration, un-check it so the only selected input colorspace is YV12. ffdshow may be converting the video to YUY2 if it's selected. The FrostyBorders versions attached to this post will convert YUY2 to YV16 and back automatically.

Here's a suggestion for an ffdshow script for your 21:9 display. I had to look up the standard resolutions and make some assumptions, so I've assumed the resolution is 2560x1080 and therefore the exact aspect ratio is 64:27.

This script will crop the sides of any video with a DAR greater than 64.27 to 64.27.
Any DAR between 64:27 and 16:9 isn't cropped and only borders are added to the sides.
Between 16:9 and 1.5 the top and bottom is evenly cropped to make the video 16:9, then borders are added to the sides.
Any DAR less than 1.5 is cropped to 1.5 by cropping more from the bottom than the top (TCRacio=0.3), then borders are added.
Depending on the source resolution the output is either (edit) 2560x1920, 2048x864 or 1280x540.

Let me know if it does the job.

clip = last
W = width(clip)
H = height(clip)

# If the source is anamorphic the correct pixel/sample aspect ratio
# must be specified if there's no SAR in frame properties.
# For example, 64.0/45.0 for a PAL 16:9 DVD.
# SAR must be float (not an integer)

SAR = undefined()

# Cropping
# CR and CB must be negative (or zero)

CL = 2
CT = 2
CR = -2
CB = -2

VideoDAR = float(W - CL + CR) / float(H - CT + CB)
VideoDAR = !defined(SAR) ? VideoDAR : VideoDAR * SAR
TCRatio = (VideoDAR >= 1.5) ? undefined() : 0.3

CropDAR = (VideoDAR > (64.0 / 27.0)) ? 64.0 / 27.0 : \
(VideoDAR >= (16.0 / 9.0)) ? 0.0 : (VideoDAR >= 1.5) ? 16.0 / 9.0 : 1.5

NewW = (H > 864) ? 2560 : (H > 540) ? 2048 : 1280
NewH = (H > 864) ? 1080 : (H > 540) ? 864  : 540

return FrostyBorders(NewW,NewH, CL,CT,CR,CB, InSAR=SAR, CropDAR=CropDAR, TCRatio=TCRatio)

For the attached functions:
YUY2 is converted to YV16 by FrostyBorders. The output is converted back to YUY2.
Added a couple of missing Avisynth version checks to "FrostyBorders 2024-12-21.avsi"
Fixed the float check for the CropDAR argument.
Only the BoxBur version has a BPlugin argument.
BPlugin = 0 Disables blurring completely.
BPlugin = 1 Selects FastBlur for blurring (it's the default).
BPlugin = 2 Selects BoxBlur for blurring.

[thebib62]

Let me know if it does the job.

clip = last
W = width(clip)
H = height(clip)

# If the source is anamorphic the correct pixel/sample aspect ratio must
# be specified instead of undefined(). For example, 64.0/45.0 for a PAL 16:9 DVD.
# SAR must be float (not an integer)

SAR = undefined()

SAR = defined(SAR) && IsFloat(SAR) && !IsInt(SAR) && (SAR > 0) ? SAR : 1.0

# Cropping
# CR and CB must be negative (or zero)

CL = 2
CT = 2
CR = -2
CB = -2

VideoDAR = float(W - CL + CR) / float(H - CT + CB) * SAR
TCRatio = (VideoDAR >= 1.5) ? undefined() : 0.3

CropDAR = (VideoDAR > (64.0 / 27.0)) ? 64.0 / 27.0 : \
(VideoDAR >= (16.0 / 9.0)) ? 0.0 : (VideoDAR >= 1.5) ? 16.0 / 9.0 : 1.5

NewW = (W >= 2560) || (H > 900) ? 2560 : 1920
NewH = (W >= 2560) || (H > 900) ? 1080 : 810

return FrostyBorders(NewW,NewH, CL,CT,CR,CB, InSAR=SAR, CropDAR=CropDAR, TCRatio=TCRatio)

Seems to be working great, thank you. I will report any issues that I come across, although looks unlikely, thanks to your hard work.
I noticed that script is a tad bit different than what was used before. Is that a case of better optimized scripting on your part?
Would it be possible to make the same above script for my tablet? It's display resolution is 2048 x 1536.

[hello_hello]

It's not all that different. The script in the second post bypasses FrostyBorders when the source is close to 16:9. I think that was your idea to prevent the script adding tiny borders. It has more resizing options, as off my head I know several exact 16:9 resolutions, but for 64:27... not so much. I've edited the script to change two lines though. There's three resizing dimensions now that are all mod4, and the function should only upscale.

Edit: I've changed the script so the SAR is undefined unless you specify one, as that way FrostyBorders can automatically use the SAR in frame properties, if one exists, although a SAR probably isn't written when ffdshow it the source filter. I've also edited the original script in post #2.

clip = last
W = width(clip)
H = height(clip)

# If the source is anamorphic the correct pixel/sample aspect ratio
# must be specified if there's no SAR in frame properties.
# For example, 64.0/45.0 for a PAL 16:9 DVD.
# SAR must be float (not an integer)

SAR = undefined()

# Cropping
# CR and CB must be negative (or zero)

CL = 2
CT = 2
CR = -2
CB = -2

VideoDAR = float(W - CL + CR) / float(H - CT + CB)
VideoDAR = !defined(SAR) ? VideoDAR : VideoDAR * SAR
TCRatio = (VideoDAR >= 1.5) ? undefined() : 0.3

CropDAR = (VideoDAR > (64.0 / 27.0)) ? 64.0 / 27.0 : \
(VideoDAR >= (16.0 / 9.0)) ? 0.0 : (VideoDAR >= 1.5) ? 16.0 / 9.0 : 1.5

NewW = (H > 864) ? 2560 : (H > 540) ? 2048 : 1280
NewH = (H > 864) ? 1080 : (H > 540) ? 864  : 540

return FrostyBorders(NewW,NewH, CL,CT,CR,CB, InSAR=SAR, CropDAR=CropDAR, TCRatio=TCRatio)

I just got hit with a distraction so I'll have to return later.