SimpleSlugUpscale - Scaling helper script, arbitrary size and PAR input/output

[Robert Martens]

Latest release (http://www.gyroshot.com/files/simpleslug/SimpleSlugUpscale.avsi) (currently 1.13)

SimpleSlugUpscale is a QTGMC-based helper script for AviSynth 2.5.x, designed to ease the process of cropping, scaling, and/or letter/pillar/windowboxing clips from one size and shape to another, while taking pixel and display aspect ratios into account.

There are no requirements for progressive input, but interlaced footage needs QTGMC (http://forum.doom9.org/showthread.php?t=156028) and its dependencies, all of which are linked from that thread. I've also prepared a brief tutorial (http://www.gyroshot.com/upscale1.htm) on the use of SimpleSlug for upscaling, but it's mainly for people unfamiliar with Avisynth.

Full documentation is available in the script itself, but the basics are as follows:

1.) If your input is progressive, set prog=true
2.) If your input is widescreen NTSC DV, widescreen PAL DV, or 1440x1080 HD with a DAR of 16:9, set widein=true
3.) Set size to one of the presets from the following list:

name dimensions PAR interlaced?

deint same as input same no
square square pixel equivalent of input 1:1 no
480sq 640x480 1:1 no
360sq 640x360 1:1 no
DVfullpNTSC 720x480 10:11 no
DVfulliNTSC 720x480 10:11 bottom field first
DVfullpPAL 720x576 12:11 no
DVfulliPAL 720x576 12:11 bottom field first
DVwidepNTSC 720x480 40:33 no
DVwideiNTSC 720x480 40:33 bottom field first
DVwidepPAL 720x576 16:11 no
DVwideiPAL 720x576 16:11 bottom field first
720p 1280x720 1:1 no
1080pana 1440x1080 4:3 no
1080iana 1440x1080 4:3 top field first
1080psq 1920x1080 1:1 no
1080isq 1920x1080 1:1 top field first

So, if you have progressive, anamorphic input, and you want 1920x1080p output, you'd use this:

SimpleSlugUpscale(prog=true,widein=true,size="1080psq")

To get a look at the default settings in action, see this NTSC DV original (http://www.gyroshot.com/files/simpleslug/testclip.zip) scaled up to 720p: http://www.gyroshot.com/files/simpleslug/SimpleSlugUpscale-defaults.mp4 Compressed with x264 revision 1745, 32 bit, 8 bit depth from x264.nl (http://www.x264.nl/), using --preset slower --tune fastdecode --keyint 300 --sar 1:1.

On top of that, here are some sample frames (from footage I shot or generated myself, and all hosted on my own webspace) to give you an idea of what can be achieved with SSU:

http://www.gyroshot.com/images/tutorials/upscale/thumbs/thumb-720pboxbg.jpg (http://www.gyroshot.com/images/tutorials/upscale/720pboxbg.jpg) http://www.gyroshot.com/images/tutorials/upscale/thumbs/thumb-480sqbox.jpg (http://www.gyroshot.com/images/tutorials/upscale/480sqbox.jpg)

http://www.gyroshot.com/images/tutorials/upscale/thumbs/thumb-DVfullpPALbox.jpg (http://www.gyroshot.com/images/tutorials/upscale/DVfullpPALbox.jpg) http://www.gyroshot.com/images/tutorials/upscale/thumbs/thumb-DVwidepNTSCbox.jpg (http://www.gyroshot.com/images/tutorials/upscale/DVwidepNTSCbox.jpg)

http://www.gyroshot.com/images/tutorials/upscale/thumbs/thumb-360sqboxbg.jpg (http://www.gyroshot.com/images/tutorials/upscale/360sqboxbg.jpg) http://www.gyroshot.com/images/tutorials/upscale/thumbs/thumb-357x623box.jpg (http://www.gyroshot.com/images/tutorials/upscale/357x623box.jpg)

http://www.gyroshot.com/images/tutorials/upscale/thumbs/thumb-720pbg-bgclip.jpg (http://www.gyroshot.com/images/tutorials/upscale/720pbg-bgclip.jpg) http://www.gyroshot.com/images/tutorials/upscale/thumbs/thumb-1024x768-mostnewparameters.jpg (http://www.gyroshot.com/images/tutorials/upscale/1024x768-mostnewparameters.jpg)

To give a little background on the origin of this thing, I've been a member of the DV Info Net forums (http://www.dvinfo.net/forum) since 2003, and in the past few years the subject of SD to HD upscaling has occasionally cropped up. With more and more people getting into HD video production, now and then someone would find themselves needing to stick an old SD clip into an HD project, and they weren't always elated with the results. Having spent several years toying with Avisynth in my spare time, and having discovered the wonder of TempGaussMC, I took the opportunity in one of those discussions (http://www.dvinfo.net/conf/non-linear-editing-pc/140965-how-upscale-sd-hd.html) to recommend that combination for the task of deinterlacing and upconversion, and I walked another member through the process of installing all the software and piecing together a script.

When the subject came up again in February 2010, I started preparing an updated, better informed, much cleaner and hopefully more understandable tutorial, and swiftly realized how complicated the whole thing was to explain. I thought a script to take care of as many of the details as possible would be a good idea, hence SimpleSlug. "Simple" for the few adjustments necessary to get usable results, "Slug" to reinforce the lengthy nature of the processing involved.

I finally got around to starting a thread here with the release of version 0.7g, and since then have produced a few more revisions. Over that time the script has inched away from being a DV-to-HD upscaling script and closer to being a general purpose resizing assistant. My choice of default deinterlacer (now QTGMC with the advent of all -Vit-'s handy presets), and default settings, is still based primarily on my testing with DV sources being scaled to 720 output, but the script handles a bunch of other things, too.

I can't pretend to be an expert, and though I've done my best to keep this script clean and offer a set of useful features, I'm certainly not averse to suggestions or corrections. That goes for both the script and the tutorial, which I tried to write as an accurate, but relatively simple way for people who aren't Avisynth gurus to get some use out of QTGMC and the scaling algorithms AS offers.

Please, by all means, feel free to offer ideas for improvements, or let me know that I've done something exceptionally stupid. I have a way of turning everything I do into a Rube Goldberg contraption, and I've already done some real bonehead things in earlier revisions of the script, so I won't be surprised to find yet another way I've taken the long way around in accomplishing some goal. Check the bottom of the script's page (http://www.gyroshot.com/simpleslug.htm) to find old versions and you'll be able to see what changes I've made so far; if nothing else I hope this script and its predecessors (the following posts refer variously to versions 0.7g onward) prove useful to learn from.

[2Bdecided]

I think this is a great idea.

There are quite a few suggestions in the DV upscale thread (in the DV sub-forum) which could be included. If anyone has time...!

Cheers,
David.

[Gavino]

Robert, thanks for producing this and congratulations on a well-written tutorial.

A couple of comments:
- your function expects the input to be 4:3 DV. How about an option to treat the input as 16:9 (anamorphic) DV?
- BicubicResize does not work as the resizer. This can be fixed by using named arguments in place of positional arguments in the resizer calls, eg replace
Eval("shtrclp." + resize + "(outwidth,outheight,cropleft,croptop,cropwidth,cropheight)")
by
Eval("shtrclp." + resize + "(outwidth,outheight,src_left=cropleft,src_top=croptop,src_width=cropwidth,src_height=cropheight)")

[2Bdecided]

I haven't run it, but it looks like it's generating interlaced content by generating half-height fields (by simple resizing of the bobbed content) and weaving them.

If so, that's not right at all. You should take the full height bobbed output, and do separatefields().selectevery(4,0,3).weave() You need to specify field order (assumebff() for DV, assumetff() for HD) first. I doubt you'll need a vertical filter since the image will always be vertically soft at this point AFAICT.

Cheers,
David.

[Robert Martens]

Thanks for the feedback, I appreciate the notes!

your function expects the input to be 4:3 DV. How about an option to treat the input as 16:9 (anamorphic) DV?

I thought about this a week or so ago, but worried about how to be sure of the input pixel aspect ratio, since as far as I know one can't retrieve that info from the input clip. Now that I spend a few more brain cells on the subject, I realize I could just make it a function parameter, and trust people to know what their input is. Added to my todo list.

BicubicResize does not work as the resizer. This can be fixed by using named arguments in place of positional arguments in the resizer calls ...

I note this in the documentation, but named arguments is such a simple solution I'm kicking myself. Thank you for reminding me, I'll get that done in no time.

I haven't run it, but it looks like it's generating interlaced content by generating half-height fields (by simple resizing of the bobbed content) and weaving them.

If so, that's not right at all.

You're correct, that's what I'm doing. I was worried I'd end up doing something wrong with the interlaced outputs, but checking my video post-SimpleSlug with AssumeBFF().SeparateFields() (AssumeTFF() for the 1080i outputs) showed no back-and-forth jumping that you usually get with field order problems, and I thought I was in the clear.

Am I to understand it's incorrect even if it seems to be working? I would hardly be surprised, considering how happy I was with myself (that usually means I've done something screwy), and it should prove a fairly simple update in any event.

[ron spencer]

very interesting...thanks!!!

[Gavino]

Now that I spend a few more brain cells on the subject, I realize could just make it a function parameter, and trust people to know what their input is.
Yes, that's what I meant.
checking my video post-SimpleSlug with AssumeBFF().SeparateFields() (AssumeTFF() for the 1080i outputs) showed no back-and-forth jumping that you usually get with field order problems
It's not a field order problem, but a field alignment problem. Correct interlacing requires the two fields to be vertically offset from each other, so you should see the picture bobbing up and down after a SeparateFields. The fact that it looks OK actually indicates that it's wrong.(!) To get the correct spatial relationship between the fields, you need to do as 2Bdecided says, produce full-height double-rate progressive frames and apply SeparateFields().SelectEvery(4,0,3).Weave().

[Robert Martens]

The fact that it looks OK actually indicates that it's wrong.(!)

Excellent, thanks for the briefing! Your two suggestions are already implemented, and now that I understand the interlacing problem I'll get to work on it immediately.

Ron, you're quite welcome!

EDIT: There you go! Haven't updated my site yet, but the new script is up, and the link in the OP will get you the proper file. I figured mistakes like these weren't worth a full point release, so it's version 0.7h now. While I was at it I swapped out the code block with the updated script, too.

I added a boolean parameter, 'widein', that can be enabled to allow widescreen input processing, changed the resizer calls to use named arguments instead of positional, set up the interlaced processing as 2Bdecided described (I now get proper field order AND up-and-down shifting when using SeparateFields() on SimpleSlug's output), moved my Assert for the clip dimensions to the top (no sense worrying about anything else if the clip's the wrong size), and broke a few things onto new lines to keep the script a reasonable width.

[Undead Sega]

Even though this seems and looks really great, but at the same time i dont want to sound noobish as well, but is it possible if u can tell me a simple (but slightly detailed) explaination of what your script or function or filter does? :D Not for me but also for some others here who dont understand :)

[Robert Martens]

Ah, yes, I suppose I can go a little overboard with my writing, sorry.

To try and summarize what I described in the first post, the simplest explanation would be that this script takes an interlaced DV video clip as input, and turns it into one of several HD, or just widescreen DV, output formats (a full table of possible values for the 'size' parameter is available in the downloadable version of the script, linked right up at the top of the thread).

Since there are more funny little details involved in doing this correctly than one might think, the script is meant to take most of the math and decision making out of the user's hands, letting you focus on just getting results. There's plenty to tweak, if you eventually decide to, but the defaults should work quite well for most people.

What does it actually do? Strictly speaking, not much of anything. TempGaussMC handles the deinterlacing, and Avisynth's internal resizers do the upscaling. My script is only supposed to be a less stressful way to put the pieces together. There's a staggering array of possible processing combinations, and my intent was to ease the pain of figuring it all out.

If you want a step by step walkthrough of the script's logic, I suppose I could whip something up, but I don't want to overwhelm you with details. There's not much ground between this explanation and a multi page essay on all the nooks and crannies of how this thing works.

[Undead Sega]

hmmm very interesting, so itis basically an upscaler yes? if so, what method of resizing does it use?

i am aware that TempGaussMC is used for deinterlacing, but couldnt one already deinterlaced footage and have it scaled to the desired resolution? Im still confused. And does it have to be DV video specifically as the input?

[Robert Martens]

I hesitate to call it an upscaler, since I don't do any of the work myself. The script doesn't examine pixel input values, or calculate new output pixels, it just decides what arguments to pass to the resizer.

The resizing technique, by default, is BlackmanResize, since I've had great success with that in the past; you can, nonetheless, choose whichever scaler you prefer. If you want Spline64, for example, you would pass that in as the value of the 'resize' parameter:

SimpleSlugUpscale(resize="Spline64Resize",size="720p")

Change 'size' as appropriate, of course, depending on the output you wish to achieve.

Accepting progressive input may be something to add for future revisions, but right now all that's accepted is interlaced. Strictly speaking, of course, the script doesn't actually check for this; if you'd like, try passing in a progressive clip and see what happens. I can't guarantee you'll have success, mind you (all I have for test clips at the moment is a bunch of interlaced PAL and NTSC DV) but you're welcome to give it a shot.

Finally, no, the video doesn't actually have to be in the DV25 format; only "DV size", which means 720x480 and 720x576. The cropping, performed before the upscale of the video, depends on those starting frame dimensions to produce output with as accurate an aspect ratio as possible. Since the script is mainly aimed at the world of video production, which saw a shift from using DV size video in the standard definition days, to all sorts of HD formats over the past few years (the problem becoming that sometimes DV clips need to fit into HD projects; footage from a crash cam, for example, or some critical piece of file footage for a documentary that's only available in DV), I felt the restriction to DV sizes wouldn't be a major hindrance to most people looking to use a script of this sort.

[Robert Martens]

And does it have to be DV video specifically as the input?

It's taken a month, but I've finally addressed this.

I couldn't resist. Someone contacted me about SimpleSlug, asked a few questions, and made a comment in passing that led me to believe they thought the script could handle both anamorphic AND square pixel widescreen footage. At the time I only accepted widescreen DV, so I said to myself "Self, you should tweak the script ever so gently to allow a slightly greater range of input sizes".

Well, everything with me turns into a project, so a few weeks after my brilliant idea (and a few days later than I'd planned, thanks to a family member's computer virus), I give you SimpleSlugUpscale 0.8 (http://www.gyroshot.com/files/simpleslug/SimpleSlugUpscale08.avsi), which will accept any size input with any pixel aspect ratio, and scale it to any size and PAR output.

I was so happy with previous versions not being wider than a page (as displayed on my 1024x768 CRT), or much taller than one, but that's gone right out the window in favor of legibility. White space abounds in this script, in an attempt to make things more understandable (for myself, if no one else), and as such I must refrain from posting a code block here. Trying to twist it into something that would be readable on a message board could be a bit of a challenge, to say the least.

To summarize the changes, the script now:

-Allows any size and PAR input and output ('outwidth', 'outheight', and 'PARout' are used to define custom target sizes)

-Allows any deinterlacer

-Supports progressive clips by 'prog' boolean, which will bypass deinterlacing and go straight to cropping, scaling and/or boxing

-Has a revised box function that does pillar or letterboxes depending on input and output shape

-Contains ep0 and ep1 parameters, to allow extra parameters for resizer (taps for Blackman and Lanczos, b and c for Bicubic, p for Gauss)

-Contains PARin and PARout parameters, to specify custom pixel aspect ratios (assuming presets don't properly handle your footage)

-Has lost the 'croptop' parameter, its functionality replaced with 'vshift' ('hshift' also available)

-Features 'boxcolor' to set color of pillar/letterbox (integer, either an RGB value or one of the global variables defined in AviSynth 2.5\plugins\colors_rgb.avsi)

-Also features 'boxbgblur' to change amount of blur for "boxbg" size modes

-No longer has YV12 conversion built in; this must be handled before SimpleSlug is called. If you're using RGB footage and an RGB deinterlacer, you won't need any conversion. Same for YUY2 with a YUY2 deinterlacer. By default I'm using TempGaussMC, as always, so you'll need to produce YV12 input with either the 'pixel_type' parameter of your source filter or a ConvertToYV12(interlaced=true) filter before you run SSU.

-Defaults output sizes to mod 8, but this behavior can be changed with 'modw' and 'modh' (will always Floor to the nearest multiple that's below the target output size for a given axis)

-Uses a greater number of TGMC defaults for the "balance" 'qual' setting; with the perspective of some time, I see now my changes had a tendency to make video look too artificial. Bringing back TempGauss' defaults makes for a better result, to my eye. You can certainly adjust things to suit your own taste, if you feel so inclined.

From my research here on Doom9, I only now get the impression that I've ended up duplicating the work of at least a few other members, namely mikeytown2 and his ZoomBox (http://forum.doom9.org/showthread.php?t=135776) function--among others--but this new set of features seemed useful for SimpleSlug, and I needed the practice working with Avisynth. I wasn't looking to steal anyone's thunder, I just got carried away.

I suppose this script isn't very "simple" anymore, if you use the full array of features, but there are only four things you must do to get this new version working: convert interlaced video to the proper color space for your deinterlacer, set 'prog' true if the input is progressive, set 'widein' true if it's anamorphic, and choose a 'size' option from the list (http://www.gyroshot.com/simpleslug.htm#sizes) (pay close attention to that, names have been added, removed, and changed from prior releases). Most everything else should be taken care of automatically, so I think the script should still manage to ease the pain of all this scaling business for the uninitiated. Not that I'm such an expert, but you know what I mean.

I've cleaned the script up as much as I can for now; I'd love to sit on this thing until I'm absolutely sure it's perfect, but nothing's ever perfect, so there it is. It's still pre-1.0, anyway, so brace yourself for bugs. Hopefully there won't be many, since I've tested input of quite a few shapes and sizes: 720x480, 720x576, 1280x720, 1920x1080, 1440x1080, 1080x1920 (yes, tall and narrow), 720x1280, 1280x768, 848x480, 320x240, 320x210, 4520x720, 2048x1152, all the sample clips I've been able to find, shoot, or generate. I've tried output that was each of those sizes, plus a dozen others. Some 4:3, some 16:9, some 1:1, some real oddball ratios, and some output dimensions that were literally odd, as is possible with RGB processing.

Upscaling defaults, as it always has, to BlackmanResize, but now I default to Bilinear for downscaling. This can, of course, be overridden by the 'resize' parameter, so everyone's free to choose their poison. I know there's a concern for excessive high frequency detail when downscaling, but in my admittedly informal tests I haven't found any problems with taking 1920x1080 from a Canon XF series camera, or 2048x1152 shot by a RED One, down to NTSC DV resolution. I scaled down to 720x480, compressed with Cedocida, brought the clips into Avid Liquid, then sent them out over the breakout box component outputs to my old Sony CRT, and it was gorgeous, no twitter, didn't look overly sharp. The Canon XF clip was interlaced, and as per the defaults I deinterlaced it with a simple Bob() (triggered if the output height is 1.5 times or more smaller than the input height; less severe downscales use my "low" TGMC preset). Take that with a grain of salt, though, as I haven't had any experience with downscaling issues. If you find my defaults objectionable, feel free to override them, and please let me know if you have suggestions.

I think I've tested a good number of possible input and output scenarios, but there can never be too many tests, so if you have any footage that's an interesting size, shape, or pixel aspect ratio on your hands, I'd appreciate if you could try it out with SimpleSlug and see what happens.

[mikeytown2]

I'm sure you could get some good ideas from my scripts in this thread for SimpleSlugUpscale
http://forum.doom9.org/showthread.php?t=135776

[Robert Martens]

When Seagate's big firmware problem was first announced, however long ago that was, I checked my serial numbers with their online form. Three times, over the months following, I was told my drive wasn't affected. An update was available for this model, but not my serial number, so I assumed "it's dangerous to install firmware you don't actually need" and decided not to fix what didn't appear to be broken.

So much for that. A couple of weeks ago, while trying to diagnose a Windows hang by way of analyzing CrashOnCtrlScroll-generated memory dumps, my system refused to POST. More time was spent chasing wild geese than I'd like to admit, but I eventually found the hard drive was the cause (of the BIOS hang; turns out the OS hang was an antivirus/driver interaction). Some research led me to a DIY solution (http://sites.google.com/site/seagatefix/Home), and while waiting for my USB-to-TTL adapter to arrive, I got the urge to tinker with SimpleSlug again. I went to work on my laptop, and two weeks later I've got an update available for everyone to play with:

SimpleSlugUpscale 0.9 (http://www.gyroshot.com/files/simpleslug/SimpleSlugUpscale09.avsi)

I've since restored access to my desktop, and all my test clips, so I've been able to go through my usual testing procedure for this release. Hopefully there aren't any showstopping bugs.

Believe me, I worry about feature creep as much as anyone else, but in this case the updates were features I would want the script to have if I were using it for a project. I'd previously considered most of the ideas, but dismissed them as too far beyond my skillset. A few months of practice seems to have made a difference, though, because I figured most of them out.

With regard to the script's existing interface, nothing has changed. The same instructions apply as they did for the last version, and the presets are named as they have been for the last few versions (in fact, I've slightly improved the reliability of the 'size' string parsing), so any scripts you're using should still work, even when using positional arguments.

If you'll pardon me, for this post I'm only going to detail changes from the last version; I type enough as it is, and I've been over the basics in this thread already. New users would do well to download the script and read the documentation, which having itself been updated should be a bit easier to handle.

The major improvement for 0.9 is the auto calculation of custom output dimensions when given less-than-complete information. A trivial example would be if you know you want square pixel output that's 640 pixels wide, and has an aspect ratio of 2.35, but you don't know the vertical dimension required to achieve that. Entering


SimpleSlugUpscale(outwidth=640,DARout=2.35)


would produce this:

http://www.gyroshot.com/images/tutorials/upscale/outwidth640DARout235.jpg

Without the Subtitle(), of course, that's just for the purpose of demonstration. 640 / 272 = 2.352941, and you have your aspect ratio! Observant minds will note this paragraph has been edited since I first posted it; I've silently rolled back a change I made in the original release of 0.9 that I only thought I'd sufficiently tested. Used a Ceil() when it should have been Round(), and though the decision to do that was originally made with the best of intent, the corner cases handled by the Ceil() aren't worth the slight aspect ratio error introduced.

This auto-size calculator works whether you enter outwidth or outheight, and doesn't require a display aspect to function correctly. If you only use


SimpleSlugUpscale(outheight=768)


you'll get square pixel output that's 768 pixels tall and has an aspect ratio that matches the AR of your input. If you enter both outwidth and outheight, your input will be cropped to match the output shape (unless you also enter "box" or "boxbg" for 'size', in which case the input will be padded). Just like 0.8, the crop area can be shifted as necessary with 'hshift' and 'vshift', and should you exceed the maximum values for a given input/output combination, an error message will let you know (and present the maximum).

While I was at it, I added 'boxshifth' and 'boxshiftv' to let you slide the center video left and right or up and down, respectively. These options are better demonstrated than explained, so I've prepared some sample frames (all, including the one above, using input footage I shot or rendered myself, and hosted on my own webspace). I stuck with JPEGs since I'm not showing off compression quality, only frame sizes and shapes (click for full size):

Sample screenshots moved to OP with the release of SimpleSlug v1.00

The "box" and "boxbg" modes also respect modw and modh, even when using boxshifth or boxshiftv, so the borders where the bars meet the center should always fall on multiples of 16, by default (as I said, however, height will be mod 8 for 360 and 1080 presets).

As one last bit of polish, I changed my default 'resize' setting to include an AviSynth version check, so if you're not using 2.5.8 you'll default to Lanczos4 upscaling. I've successfully loaded and used the script in AviSynth 2.5.6, 2.5.7, 2.5.8, and SEt's 2.5.8MT. I think that covers most versions still in use, but correct me if I'm wrong.

How useful all of this will be to anyone, I really can't say, I was just bored and had a lot of free time on my hands. As I said, I just added what I thought the script should, on principle, have if it's going to handle the kind of cropping and resizing I intend it to. Since it was reasonable for me to add this stuff in, I thought it was only the responsible thing to do.

[Robert Martens]

All right, I know you're all sick of me bumping this thread every couple of months, so I'll try to get to the point and get out of here.

SimpleSlug v1.00 (http://www.gyroshot.com/files/simpleslug/SimpleSlugUpscale1.00.avsi) is now available, with quite a few minor changes, but also a few big ones worth reviewing:

-QTGMC is now the default deinterlacer. The presets from version 0.9, that use TempGaussMC_beta2, are still present, if you prefer doing things that way, but the wide variety of presets available in QTGMC won me over.

-For downscales from interlaced source material, the script now downscales horizontally before deinterlacing. Looks just as good, runs much faster for significant downconversions.

-Thanks to the way I accomplished the horizontal resizing, you can now use a separate vertical resizer, with its own parameters, by way of 'resizev' and 'ep2' and 'ep3'. If you use this option, the existing 'resize' will only determine the horizontal resizer.

-Although my personal motto remains "windowboxing is for suckers", I have finally gotten around to adding windowboxing capabilities to SimpleSlug. Adding "window" to a 'size' preset will override all other custom box dimensions, and keep your input at its original size (accounting for both input and output PAR, so the end result will look the way it should).

-If you want custom windowbox sizes, however, you can instead use "box" in your size preset and define boxwidth and boxheight, together, individually, or in concert with the existing boxvideoDAR.

-If you like you can also use 'bgclip' to dictate a separate background clip. You'll need to make sure ahead of time that it's the same framerate, duration, and colorspace as your main input clip, otherwise you're in for some strange behavior. If it's not a progressive, square pixel clip, you can use 'bgargs' to deal with it properly: the background is generated by calling SimpleSlugUpscale from within SimpleSlugBox, and bgargs is the string of arguments used. I'd recommend sticking with square pixel, progressive clips for your backgrounds and avoiding bgargs altogether, but if you're feeling adventurous the capability is there.

-'boxmode' will let you use Overlay or Layer to stick your center clip on top of the background, and 'boxargs' lets you pass all of your options in. boxmode="overlay",boxargs=""" mode="add" """, for example. Those two filters require colorspace conversions, however, so I've updated my StackVertical/Horizontal nest to allow you to shift the center clip partially or completely offscreen, if you want, just as you can with Overlay and Layer. This change also allows your box to be larger than your output frame on one or both axes.

-In conjunction with the windowboxing capabilities introduced in v1.00, you have preset box positions using 'boxpos'. "Left", "top", "right", "bottom", or a combination of those will set the box in those places to start. This is cumulative with the boxshift parameters, so using boxpos="topleft",boxshifth=32,boxshiftv=32 will stick the box in the top left corner of your output frame, 32 pixels away from each edge, regardless of input and output sizes.

While I was at it, I both cleaned up the Basic Use section to make it more accessible, and added some probably-too-detailed comments throughout the script, to try and clear up my intentions at various points. I also compressed a new sample clip showing off the version 1.00 defaults, and prepared a couple of additional sample frames, all of which you can find with the last batch of samples, relocated from my previous post up to the newly-updated OP.

Once again, I've done a fair bit of testing on this, but I can't catch everything. If you're interested in this script, but can't get it to do something you want it to, let me know and I'll see what I can do!

[aegisofrime]

Hi, just stumbled onto this script! I have a question about something I have been attempting to do...

I have a DVD that is a mixture of letterboxed 16:9 content and full 4:3 content. What I want to do is that, for the letterboxed parts, crop away the black bars at the top and bottom, and interpolate that to full 16:9 720x480 resolution. For the 4:3 parts, pillarbox it so that the whole video will be 16:9 aspect ratio. I hope I'm making sense here! Is that possible with your script? Thanks!

[Robert Martens]

It should be possible, but I'm not a DVD expert (I mostly work with DV material), so bear with me.

There's a bit of legwork involved, but I'd imagine something like this would work:

letterboxp1 = last.Trim(0,5000).AutoCrop(mode=0).SimpleSlugUpscale(size="DVwidepNTSC",PARin=10.0/11.0)
fullframep1 = last.Trim(5001,7000).SimpleSlugUpscale(size="DVwidepNTSCbox")

letterboxp1 + fullframep1

You'd first need to select the letterboxed portions of your script (just threw in some random Trim values for demonstration purposes), crop off the bars with something like AutoCrop, then run it through SSU with a target size of DVwidepNTSC and an input pixel aspect of 10.0/11.0. PARin won't properly autodetect at this point since you've cropped off the borders, and the clip is no longer its original size.

Then, for the full frame content, trim to its extents and simply run it through SSU directly; with the full 720x480 available, the proper PAR of 10.0/11.0 will be applied automatically (though you could define it if you wanted, more on that in a moment).

Stitch them back together with + or ++, whichever is more appropriate in this case (I think +, but don't quote me on that), and you should be finished! For the first two parts, that is. You'd need to continue on with "letterboxp2" and so on.

The only problems are these: first, of course, it involves using Trim to select the various portions of your video by hand, which could be bothersome. I don't know of a better way to do it, unfortunately, since you want to crop-and-stretch some parts while padding others. Second, the value I gave above of 10.0/11.0 is the pixel aspect ratio of NTSC DV, and I can't say for sure whether or not that's correct for DVDs. If it turns out to be mistaken, though, you can always enter the correct value for PARin--also for PARout, if you're going back to DVD--and the cropping should take it into account properly.

If your DVD is not pure interlaced, you'll need to do any IVTC or other field matching work before using SimpleSlug, then pass the progressive clip in with prog=true, instead.

If you want interlaced output, you can use "DVwideiNTSC" instead, but I only just realized that's bottom field first only, while DVDs are usually top field first. Giving it a quick once over, I think I should be able to quickly throw in a parameter to let you select which field order you like. Give me a little while, I'll try it out.

This is part of my motivation for using two places after the decimal; releases can be much more granular now if I've overlooked something like this.

Done! Uploaded version 1.01, it now lets you choose a field order by way of 'interlaced', a string that can be either "tff" or "bff". If you want interlaced output for widescreen NTSC DVD, just use this:

SimpleSlugUpscale(size="DVwideiNTSC",interlaced="tff")

[Robert Martens]

I knew I'd need those extra decimal places. Updated to 1.02 (http://www.gyroshot.com/files/simpleslug/SimpleSlugUpscale1.02.avsi), with a handful of minor tweaks, but one big fix for box mode center dimensions that is the only reason I'm replying once again to this thread. A huge thank you to Nico Feragnoli for bringing the mistake to my attention!

While I was at it, I updated the preset PAL DV pixel aspect ratios after seeing henryho_hk's resizing script (http://forum.doom9.org/showthread.php?p=1457607#post1457607) and realizing his values worked better than what I'd been using. Thanks, Henry!

[henryho_hk]

You are welcome, Robert. I've got to add customized PAR in my script too.

My avs2qxvid (http://forum.doom9.org/showthread.php?t=119500) batch is using some more fancy PAR ratios that I found somewhere on the web.

[Robert Martens]

Ooh, thank you again! I see your script is using some of the values listed in these conversion tables (http://lipas.uwasa.fi/~f76998/video/conversion/#conversion_table). Through reading several aspect ratio threads here on Doom9, I was led to that page some months ago, and had planned to use those numbers instead of what I've got now, but I believe I had some sort of issue with the way I was rounding certain values at certain points in the script (that, and I couldn't find anything about widescreen ratios on that page; I just decided to stick with what VirtualDub uses in its preview pane context menu).

It's been a while since I've tested that, however, so I should probably revisit the subject. It may take a bit, though, since I'm just in the process of finishing up my first proper plugin. It turns an input clip into a mosaic built out of pieces of a custom tilesheet that you supply. Mock up a sheet of solid colors, gradients, ASCII text, whatever you want, tell the plugin the tile dimensions, and it does the rest, picking tiles according to the channel of your choosing. Nothing mindblowing, but fun to play with, and has helped me focus my efforts to learn C++. Should be finished in a few days.

[2Bdecided]

these conversion tables (http://lipas.uwasa.fi/~f76998/video/conversion/#conversion_table)...don't contain one correct PAR value anywhere in them.

Cheers,
David.

[Robert Martens]

Ah. Well then. "Looks like they know what they're talking about" is as dangerous as I thought it was, after all.

Am I to take it the values I'm using now (10:11 and 40:33 for NTSC DV and NTSC DV wide, 12:11 and 16:11 for PAL DV and PAL DV wide) are accurate?

[Wilbert]

..don't contain one correct PAR value anywhere in them.
I'm not saying all of them are correct, but ... Which one is not correct and why?

[2Bdecided]

I'm not saying all of them are correct, but ... Which one is not correct and why?The ones calculated by assuming the full ITU active picture is 702x576. It's not. It's 702x575. (He makes the same mistake with 486 instead of 485 for "NTSC").

Anyway, we've discussed this before...
http://forum.doom9.org/showthread.php?p=1072530#post1072530
!

There are several other threads, e.g. this lists the PARs etc...
http://forum.doom9.org/showthread.php?p=1451277#post1451277

Cheers,
David.

[Overdrive80]

Hi, i have been testing this filter and i obtein that results:

Original video DVD-NTSC 720x480, PAR=10/11, DAR=3:2

http://www.imagengratis.org/images/original.jpg

Original video DVD-NTSC 640x480, PAR=1:1, DAR=4:3

http://www.imagengratis.org/images/resize640480.jpg

Video upscale Option 1 Size 1440x1080p, PAR= 1:1, DAR=4:3

AssumetFF()
SimpleSlugUpscale(widein=false,size="1080pana")

http://www.imagengratis.org/thumbs/14401080upsiz.jpg (http://www.imagengratis.org/?v=14401080upsiz.jpg)

In this case, the image is cropped at the top and bottom

Video upscale Option 2 Size 1440x1080p, PAR= 1:1, DAR=4:3

AssumetFF()
SimpleSlugUpscale(widein=true,size="1080pana")

http://www.imagengratis.org/thumbs/14401080ufgf.jpg (http://www.imagengratis.org/?v=14401080ufgf.jpg)

In this other case, the image is cropped at the left and right

Video upscale Option 3 Size 1440x1080p, PAR= 1:1, DAR=4:3. In this case, Im looking for the original image without crooping but upsize.

AssumetFF()

SimpleSlugUpscale(widein=true,size="1080pana", parIn=1.185) or SimpleSlugUpscale(widein=false,size="1080pana", parIn=1.185)

http://www.imagengratis.org/thumbs/14401080ueqe.jpg (http://www.imagengratis.org/?v=14401080ueqe.jpg)

The result for me is nice, however I dont know because autocrooping when the Par Input video not is 1.185 but is 10:11.

All of modes, if i specify in argument ParIn a fraction (i.e 32/27), the result is wrong. It seems as if the function to return the truncated value of the fraction, that is 1.

http://www.imagengratis.org/thumbs/14401080ucuc.jpg (http://www.imagengratis.org/?v=14401080ucuc.jpg)

[Robert Martens]

All of modes, if i specify in argument ParIn a fraction (i.e 32/27), the result is wrong. It seems as if the function to return the truncated value of the fraction, that is 1.

I'll review the rest of your post in a moment, to see if I can figure out what's going wrong, but don't forget that entering a fraction requires that you use floating point numbers. That is, you need to type 32.0/27.0 instead of 32/27.

Update, I think I see the cause of your other problem here: you're using the 'size' preset of 1080pana ("1080p anamorphic"), which has a pixel aspect ratio of 4.0/3.0 and a display aspect ratio of 16.0/9.0. If you want 1440x1080 output with a 1:1 pixel aspect ratio, you'll need to define it by hand. There are a few ways to achieve the result you're after:

First, you can keep the 1080pana preset, but define your own output pixel aspect ratio:

SimpleSlugUpscale(size="1080pana",PARout=1.0)

This will override the default PAR for that size preset, and produce square pixel 1440x1080.

Second, if you prefer, you could always define your own dimensions:

SimpleSlugUpscale(outwidth=1440,outheight=1080)

The output pixel aspect will default to 1:1 when you define your own output dimensions, unless you also define DARout. In this case, however, 1440x1080 with square pixels is already 4:3, so there's no need to set DARout.

[Overdrive80]

I'll review the rest of your post in a moment, to see if I can figure out what's going wrong, but don't forget that entering a fraction requires that you use floating point numbers. That is, you need to type 32.0/27.0 instead of 32/27.

True, i test and now is nice. Edit 2

With scripts of you last post, the resulting video is autocrop too, and I want to keep with the original image with the band
black. So the only way to get it to assign the ParIn.

It is my opinion but I think if you rescale the video it would not crooping the video. I do not want to offend you, its great contribution. ^^

eDIT: I think that PAR NTSC is 4320/4739

[Robert Martens]

With scripts with of you last post, the resulting video is autocrop too, and I want to keep with the original image with the band
black. So the only way to get it to assign the ParIn.

It is my opinion but I think if you rescale the video it would not crooping the video. I do not want to offend you, its great contribution. ^^

No offense taken, I understand the frustration when a script doesn't work the way you expect it to. However, using the second screenshot you posted, and the first example I gave (keeping the 1080pana, but defining PARout as 1.0), I'm able to achieve the upscale without removing the black bar at the left.

Using the first screenshot, original.jpg, I can see the cropping you describe, but I believe the problem here is the fact that NTSC video, at 720x480 and a pixel aspect ratio of 10.0/11.0, actually has a display aspect ratio of 15:11, which is slightly wider than 4:3, which means a certain amount of cropping is to be expected.

I had planned to offer a parameter named 'DARin', to let people more easily handle situations like this without requiring you to calculate an appropriate input pixel aspect ratio, but I ran into some sort of problem that I can't recall off the top of my head. The variable actually exists internally, but something went wrong when I tried exposing it as a parameter.

I'm still finishing up that plugin I mentioned a few posts ago, but once it's done and made public I'll get back to work on this script. If I review my work with a fresh perspective I might see a way around whatever issues I ran into last time.

I think that PAR NTSC is 4320/4739

I used to think the same thing, but it seems we're wrong: the topic actually came up at the top of this page, check the links 2Bdecided mentioned to find out more.

[Overdrive80]

Well, I have the video and cant do it as you said. However, i redefined variables

cropwidth = 0
cropheight = 0
cropleft = 0
croptop = 0

As they say in my country, its to kill a fly with a cannon, but for now I serve. Thanks Robert.

EDIT: Without redefined variables, with this code I got what I wanted. Simply, firs resize and after upsize ^^

Spline36Resize(720,540)

AssumetFF()

SimpleSlugUpscale(size="1080pana", parout=1.0)

[Overdrive80]

I hope that it, could be interesting. ^^ http://en.wikipedia.org/wiki/ATSC_Standards

[Robert Martens]

Just to get it out of the way up front: I'm not sure if this issue deserves its own thread, but I noticed while working on the 1.10 update that FindStr() is case sensitive. I've found this to be true in 2.5.6, 2.5.7, 2.5.8, SEt's 2.5.8MT, and the September 27th, 2009 2.6.0 alpha. I imagine the behavior may be intentional, but the documentation and wiki show an example, searching the string "AviSynth" for the string "syn" and getting a return value of 4, that doesn't actually work. Can anyone confirm whether it's a bug in the software or an oversight in the docs?


With that out of the way: SimpleSlugUpscale 1.10 (http://www.gyroshot.com/files/simpleslug/SimpleSlugUpscale1.10.avsi)

Despite the time gap since 1.02, this doesn't represent three months worth of work. It's more like two and three quarters being distracted by other obligations and one week of scripting and testing, but I managed to add a few useful things:

-I took a look at what I'd mentioned to Overdrive80 earlier, and sure enough, it was only a matter of coming back with a fresh perspective. After a moment pondering a chicken-or-egg dilemma I managed to get DARin working, so now if you want to force SimpleSlug to treat your footage as a certain shape, you no longer need to figure out the pixel aspect ratio (though that's still an option). Revisiting the example Overdrive posted, this syntax can now be used in lieu of my earlier suggestions:

SimpleSlugUpscale(outwidth=1440,outheight=1080,DARin=4.0/3.0)

-When I found out about MeGUI's ability to read two global variables describing a clip's display aspect numerator and denominator, I jumped at the chance to add globalDAR, globalDARnum, and globalDARden. globalDAR is false by default, since no one wants global variables forced on them, but turning this on gives you access to the numerator and denominator of DARout. By default the variables are named megui_darx and megui_dary, but you can define your own names through globalDARnum and den.

-I adjusted 'shtrhack' a bit to allow rudimentary usage of QTGMC's motion blur system. The settings of true and false still work as they did in past releases (Merge and SelectEven, respectively), but now you can also set the variable to the string "QTGMCdefault", which will turn on motion blur in QTGMC, though only using its defaults. I didn't want to get too crazy with extra parameters here, so if you want finer control over the settings, keep shtrhack set to false and pass in your own 'qual' string. For example:

SimpleSlugUpscale(qual="QTGMC(MotionBlur=3,ShutterAngleOut=360)")

-Finally, I threw in a try...catch statement to limit the number of threads used by NNEDI3 (EdiThreads in QTGMC). Coupled with a generous SetMemoryMax (1200 on a system with 2GB of physical RAM, about 1700 free), I managed to complete a 41,225 frame render using the SimpleSlug defaults, which is more than I've been able to say recently. It was only a DV resolution input clip, though, as I don't have any lengthy 1080i material to test with, so try not to get your hopes up that this'll help HD much. This is another last minute idea, and it could always blow up in my face, but it seems to help, and I finally got a try block to work the way I wanted it to, so at least I learned something. If you want further control over EdiThreads, you'll need to use 'qual' to call QTGMC yourself, as above.

Nothing major beyond that, I'm afraid. Some grammar cleaned up, typos fixed, I added some more whitespace to make the script easier to follow, but that's about it. I've got some ideas for future releases, and I'm excited to get to work, but it'll take me a while to slog through them, and I figured I should get this out as soon as possible.

[Gavino]

I noticed while working on the 1.10 update that FindStr() is case sensitive. I've found this to be true in 2.5.6, 2.5.7, 2.5.8, SEt's 2.5.8MT, and the September 27th, 2009 2.6.0 alpha. I imagine the behavior may be intentional, but the documentation and wiki show an example, searching the string "AviSynth" for the string "syn" and getting a return value of 4, that doesn't actually work.
You're right - the implementation simply uses the strstr C library function, which is case-sensitive.
I imagine it has always been that way - whether by design or by oversight, I dont know. It certainly seems inconsistent with the string comparison operators ("==", etc), which are not case-sensitive. And, as you say, it does not match the example in the docs.

Perhaps you should start a new thread in the Development forum to discuss this.

[Robert Martens]

SimpleSlugUpscale 1.11 (http://www.gyroshot.com/files/simpleslug/SimpleSlugUpscale.avsi)

Quick update to account for renamed parameter in QTGMC 3.20, made an improvement to one internal variable whose inefficiency was revealed by said QTGMC, and tidied up the presentation of my one try...catch block.

Hey, a post that's not "War and Peace"! Nice change of pace for me.

[-Vit-]

Wow, you caught that variable name change quickly! I don't usually like to change setting names, but I was getting queries from people expecting major streaks of motion blur from that MotionBlur setting. Figured it was still new enough to change, although I did realize it would affect your script...

I notice that you've flagged the possibility of QTGMC global variable clashes if people use QTGMC in your 'bgargs' setting. You might want to note that adding the setting PrevGlobals="Replace" to QTGMC will prevent any such clashes. Is it worth adding that setting to your own QTGMC calls? I guess it depends on when bgargs is called compared to your script calls. This kind of thing did worry me when I added this use of globals, but I am intending to use the system as an integral part of the QTGMC process soon (which is why the globals are not optional). I'm hoping actual problems are rare and the mechanisms I've provided will work around any that crop up.

[Robert Martens]

Figured it was still new enough to change, although I did realize it would affect your script...

Never something to worry about; I'm the one that wanted to use TGMC in the first place, and then QTGMC when it was introduced, and it's my responsibility to keep up with updates to my script's dependencies. I caught it quickly because I have far too much free time on my hands, and Doom9 is always right there in my browser's autocomplete dropdown. In this case, I'm subscribed to the QTGMC thread, so I get email notifications of new posts, but in any event I'm on the boards every five minutes checking up on things.

I notice that you've flagged the possibility of QTGMC global variable clashes if people use QTGMC in your 'bgargs' setting. You might want to note that adding the setting PrevGlobals="Replace" to QTGMC will prevent any such clashes. Is it worth adding that setting to your own QTGMC calls?

That was just an offhand comment I threw in before I uploaded the script, as I remembered the potential for bgargs to dramatically complicate this entire process. I suppose you're right about adding the note to my own docs instead of pointing people to yours to learn the same thing, I guess I didn't think that through too well. I'll add it to the next release, but right now I think far too few people would even use bgargs to make it worth an update.

As for adding the setting to my own calls, there's really only the possibility for two now. Something I realized when testing QTGMC 3.20 is that my internal 'bobbed' variable was being generated even if the user asked for a boxed output size (which would ignore 'bobbed' at the top level SSU and generate the deinterlaced output when calling SimpleSlug from within the Box function).

This pointed out to me something you touched on in your thread, and that I'd thought I'd adequately reviewed for this script, the fact that variables are initialized even if they're not used. I've now hidden the 'bobbed' deinterlacing behind a conditional, and the top level assignment is a NOP() if the user asks for letter/pillar/windowboxed output.

As such, there's only ever one QTGMC call in SimpleSlug--save bgargs, as noted--since everything I do is parse-time parameter selection, and all the QTGMC() lines peppered through it are merely strings that are later parsed by Eval().

It still may be worth adding the overwrite argument, I just need to look into it a bit more. I wanted to get a new version out to accomodate the new variable name, so any users I may actually have can use the fanciest new QTGMC you're offering. I'm working on finishing up TurnsTile 0.2.0 at the moment, which could be either a few hours or a few days away from release, but after that I'll swing back to SSU and take a deeper look at refining my approach to your global variable setup.

[-Vit-]

Thinking again, my suggestion is probably not a good idea - you'd be forcing users to upgrade QTGMC just to prevent a very remote possibility. And what I've done with the globals is... unusual - there's the possibility it will cause some unexpected problems and I'll have to backtrack. It seems that bgargs is used after your QTGMC evals anyway...

[nhope]

What options would I use in this to upscale 4:3 interlaced 720x576 PAL DV to 4:3 progressive 960x720 (square pixels)? At the moment I can only get 16:9 output. Such a preset would be very welcome.

[Robert Martens]

I limited the presets only to the most common broadcast formats that I'm aware of, just to try and keep things tidy, but what you're after is easy even without one:

SimpleSlugUpscale(outwidth=960, DARout=4.0/3.0)

or

SimpleSlugUpscale(outheight=720, DARout=4.0/3.0)

or just

SimpleSlugUpscale(outwidth=960, outheight=720)

All three options should do the same thing.

720x576 PAL DV will be autodetected on input, so the proper input pixel aspect ratio will be applied automatically, and the output PAR is assumed to be 1.0 unless specified or using a preset which isn't square pixel.

If you want a QTGMC preset beside its default (I think "Slower", but don't quote me on that), just add the 'qual' parameter to your SimpleSlug call and enter it there.

For the record, there is a preset for pillarboxed 960x720, and if anyone's interested it would be

SimpleSlugUpscale(size="720pbox")

[nhope]

Thanks Robert. Actually the first 3 options are stretching the video horizontally slightly and cropping the sides. I guess I need another option there somewhere.

This is for faux-HD on YouTube, which will recognise a 960x720 video as HD. It turns out it's actually the pillarboxed version I need, as I want to use the black sides for YouTube annotations, and the black sides that YouTube generates for the 960x720 version will not accept annotations.

[nhope]

Upon further testing, the 720box option is also stretching and cropping horizontally, within the pillarbox.

[Robert Martens]

Some cropping is to be expected, as PAL DV (like NTSC DV) isn't exactly 4:3, but slightly wider; if it's extreme, however, something else may be wrong. If you upload a sample somewhere (even just a still frame) I can take a look myself.

Of course, you could just force it to keep the entire frame:

SimpleSlugUpscale(size="720pbox", DARin=4.0/3.0)

DARin sets the input display aspect ratio, so you can force it to be treated as whatever you like.

[nhope]

The DARin=4.0/3.0 option fixes it, thanks. It would perhaps be useful to get that to happen automatically in the script. There's still some very noisy PAL DV footage here (http://www.mediafire.com/?bqcc8wyc991km5m) if you need something to test with.

Admittedly I'm now simply using this, which gives a very similar result:

AviSource("d:\fs.avi")
AssumeBFF()
ConvertToYV12(interlaced=true, matrix="Rec601")
BlackmanResize(1280,height)
QTGMC( FPSDivisor=2 )
BlackmanResize(width,720)

[Robert Martens]

Thanks for the clip! More test footage is always useful, I appreciate it.

With that clip I find, however, only the expected amount of slight cropping, and using the 720pbox size option works the way I'd expect it to without any extra settings specified.

Choosing the appropriate aspect ratio for the input is somewhat problematic, however, and I can't make it any more reliable than it already is; some cameras record DV at 720x480 or 720x576 treating the image as exactly 4:3, but as I understand it that's incorrect. The active area (same height but a width of about 704) is 4:3, but the full width of 720 makes the picture 15:11, which is very slightly wider, and will necessarily have its sides cropped off for output that's 4:3.

There's no way to tell which way a given piece of footage was shot, and I had to pick one or the other default AR for the input detection part of the script. It's a toss up from my perspective, but I'm operating under the assumption that most of the prosumer cameras used by the script's intended audience record a 15:11 frame, so that's the one I chose.

[nhope]

Ah, it's about the 704 vs 720 thing. I'd forgotten about that. So, in my situation, having shot most of my SD footage with the prosumer Sony VX2000, if I want 4:3 DV pillarboxed to 1280x720, and I want to avoid cropping the sides but keep the correct aspect ratio, it looks like I have to set the PAR of my project to 1.0667 (not the 1.0926 that Vegas gives), and then use the script I posted above. Then I get a pillarbox of 982x720 within a 1280x720 frame.

[Robert Martens]

For the script you posted, I have a couple of observations:

AviSource("d:\fs.avi")
AssumeBFF()
ConvertToYV12(interlaced=true, matrix="Rec601")
BlackmanResize(1280,height)
QTGMC( FPSDivisor=2 )
BlackmanResize(width,720)

One being that your dimensions seem to be off; as posted that will simply take your input and scale it directly to 1280x720, stretching the picture tremendously. I take it that's only a typo?

The other is that you're resizing up horizontally before deinterlacing, which is just more work for QTGMC. The preemptive horizontal resize only speeds up processing if the horizontal dimension is being reduced.

As for changing the project settings, I don't think any of that comes into play. Modifying your script a bit, you should be able to achieve your desired results with:

AviSource("d:\fs.avi")
AssumeBFF()
ConvertToYV12(interlaced=true, matrix="Rec601")
QTGMC( FPSDivisor=2 )
BlackmanResize(982, 720)
AddBorders(149,0,149,0)

1280x720 output, pillarboxed, with the center section at the appropriate aspect ratio.

Alternately, you could try (with one caveat which I'll describe presently):

SimpleSlugUpscale(size="720pbox", modw=2)

If you're happy with the results of either of those options, you can stop reading here, the following explanation goes into a bit of detail and might be offputting.

The 720 (and all other) box modes don't actually have a hardcoded dimension associated with either the width or height of the center video or boxes. Only the overall frame size is set, and the math tries to keep as much of your video visible as possible within that.

It does, however, land the box borders on multiples of modw and modh (vertical borders hit modw, horizontal borders modh). By default SSU uses mod 8, which means the center in your case ends up being 976x720, since 982 / 8 = 122.75. At a DAR of 1.3555..., slightly less than the 1.3636... of your input, the video will be very barely cropped.

By setting the horizontal modulus to 2, you'll eliminate as much of the cropping as is possible with my approach, the caveat I mentioned being that your video still won't be 982 wide, but 980 instead. This is a limitation of the script, in that I don't use AddBorders as shown up above. In what was meant to be an optimized, cleaner way of approaching this process, I generate the background using BlankClip and then crop it as appropriate to create the box bars. A video width of 982, for 1280 output, would mean bars 149 pixels wide. Since this video is all processed in YV12, however, that width can't be achieved by a crop, so the bars must instead be 150 wide. With two bars totaling 300 pixels, 1280 - 300 = 980.

This is all necessary for the "boxbg" size options, but may be something I can address for simple solid boxes. I'll definitely be looking into this for future releases.

[nhope]

One being that your dimensions seem to be off; as posted that will simply take your input and scale it directly to 1280x720, stretching the picture tremendously. I take it that's only a typo?

Should have explained that I'm frameserving from Sony Vegas, and my project settings are 960x576, PAR 1.0667. So it's entering AviSynth already pillarboxed at the correct aspect ratio. I also see on an old computer that I made a project preset of 936x576, PAR 1.0940, which achieves the same thing.

The other is that you're resizing up horizontally before deinterlacing, which is just more work for QTGMC. The preemptive horizontal resize only speeds up processing if the horizontal dimension is being reduced.

Yikes, my brain was still in downscaling mode. Thanks for pointing that out!

The AddBorders approach that you suggest is probably more elegant than what I've been doing. Thanks for suggesting it. I'll tackle the other suggestion tomorrow. Cheers

[Chymerix]

Hi Robert,

Great script you have here. I noticed one issue, though. When using "box" sizes, the audio gets stripped from the file.

I believe this is happening because you are overlaying a BlankClip() (no audio) background with the main clip. The overlay takes the audio from the first clip specified, which in this case is the blank clip with no audio.

I've fixed this by adding "audiodub(center)" to the last line of your script, but I have to remove that line when selecting anything other than a "box" size.

If you know of a better way to fix this please let me know.

Thanks!

[Robert Martens]

I am an enormous idiot. Audio completely slipped my mind, somehow, all this time. It turns out your explanation, and solution, are both on the money, although by default I don't use Overlay but StackHorizontal/Vertical, which also follow the "audio from the first clip" rule. Off the top of my head I can't remember what it is, but I think there's a reason I use bg as the first argument for Overlay/Layer instead of the center, so it looks like AudioDub is the right answer here.

I have a test version prepared that uses AudioDub, see if this helps: http://www.mediafire.com/?1q76caze4ic42cd Disable your existing version by changing the file extension or moving the file, and stick this one in your plugins directory.

The simple solution seems to be assigning the result of the giant conditional statement to a variable, then dubbing the audio from the center clip onto that as the last step. I know you said you had to remove the AudioDub line for non box modes, but testing some clips here shows the new script retaining audio in both standard and box modes, while version 1.11 does not.

Let me know how it goes; if this test script works I'll release it as version 1.12.

[Robert Martens]

Since I never heard back from Chymerix (I hope he's okay), I'm releasing version 1.12 anyway. I believe I've gotten the 'box' mode audio to work correctly, please let me know if anything is still, or newly, broken. I also made a tiny correction to my try...catch block when detecting the presence of MT Avisynth and the number of threads in use, and added more details to the appropriate comment to make sure my reasoning is clear.

On top of that, I revamped the tutorial (http://www.gyroshot.com/upscale1.htm) based on the feedback I've received through this script's life. I removed some things I didn't really care for and drastically reduced the volume of text on a couple of the pages. Hopefully it won't be quite so overwhelming anymore.