Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

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

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th December 2010, 14:38   #21  |  Link
Robert Martens
Registered User
 
Join Date: Feb 2010
Location: New York
Posts: 116
Ooh, thank you again! I see your script is using some of the values listed in these conversion tables. 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.
Robert Martens is offline   Reply With Quote
Old 15th December 2010, 15:09   #22  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
Quote:
Originally Posted by Robert Martens View Post
...don't contain one correct PAR value anywhere in them.

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 15th December 2010, 15:39   #23  |  Link
Robert Martens
Registered User
 
Join Date: Feb 2010
Location: New York
Posts: 116
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?
Robert Martens is offline   Reply With Quote
Old 15th December 2010, 19:24   #24  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Quote:
..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?
Wilbert is offline   Reply With Quote
Old 16th December 2010, 16:31   #25  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
Quote:
Originally Posted by Wilbert View Post
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.ph...30#post1072530
!

There are several other threads, e.g. this lists the PARs etc...
http://forum.doom9.org/showthread.ph...77#post1451277

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 19th December 2010, 19:10   #26  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 673
Hi, i have been testing this filter and i obtein that results:

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



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



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

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


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

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

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


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.

Code:
AssumetFF()

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


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.


Last edited by Overdrive80; 19th December 2010 at 19:19.
Overdrive80 is offline   Reply With Quote
Old 19th December 2010, 19:26   #27  |  Link
Robert Martens
Registered User
 
Join Date: Feb 2010
Location: New York
Posts: 116
Quote:
Originally Posted by Overdrive80 View Post
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:

Code:
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:

Code:
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.

Last edited by Robert Martens; 19th December 2010 at 19:37.
Robert Martens is offline   Reply With Quote
Old 19th December 2010, 19:46   #28  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 673
Quote:
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

Last edited by Overdrive80; 19th December 2010 at 20:06.
Overdrive80 is offline   Reply With Quote
Old 19th December 2010, 20:12   #29  |  Link
Robert Martens
Registered User
 
Join Date: Feb 2010
Location: New York
Posts: 116
Quote:
Originally Posted by Overdrive80 View Post
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.

Quote:
Originally Posted by Overdrive80 View Post
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.
Robert Martens is offline   Reply With Quote
Old 19th December 2010, 20:26   #30  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 673
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 ^^

Code:
Spline36Resize(720,540)

AssumetFF()

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

Last edited by Overdrive80; 19th December 2010 at 21:15.
Overdrive80 is offline   Reply With Quote
Old 20th December 2010, 02:13   #31  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 673
I hope that it, could be interesting. ^^ http://en.wikipedia.org/wiki/ATSC_Standards
Overdrive80 is offline   Reply With Quote
Old 17th February 2011, 08:41   #32  |  Link
Robert Martens
Registered User
 
Join Date: Feb 2010
Location: New York
Posts: 116
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

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:

Code:
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:

Code:
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.

Last edited by Robert Martens; 5th March 2011 at 20:14.
Robert Martens is offline   Reply With Quote
Old 17th February 2011, 18:41   #33  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
Quote:
Originally Posted by Robert Martens View Post
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.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 5th March 2011, 20:20   #34  |  Link
Robert Martens
Registered User
 
Join Date: Feb 2010
Location: New York
Posts: 116
SimpleSlugUpscale 1.11

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.
Robert Martens is offline   Reply With Quote
Old 5th March 2011, 22:20   #35  |  Link
-Vit-
Registered User
 
Join Date: Jul 2010
Posts: 448
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.

Last edited by -Vit-; 5th March 2011 at 23:04.
-Vit- is offline   Reply With Quote
Old 5th March 2011, 22:49   #36  |  Link
Robert Martens
Registered User
 
Join Date: Feb 2010
Location: New York
Posts: 116
Quote:
Originally Posted by -Vit- View Post
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.

Quote:
Originally Posted by -Vit- View Post
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.
Robert Martens is offline   Reply With Quote
Old 5th March 2011, 23:03   #37  |  Link
-Vit-
Registered User
 
Join Date: Jul 2010
Posts: 448
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...
-Vit- is offline   Reply With Quote
Old 16th October 2011, 11:09   #38  |  Link
nhope
partially-informed layman
 
Join Date: Jan 2002
Location: Bangkok, Thailand
Posts: 314
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.
nhope is offline   Reply With Quote
Old 16th October 2011, 14:23   #39  |  Link
Robert Martens
Registered User
 
Join Date: Feb 2010
Location: New York
Posts: 116
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:

Code:
SimpleSlugUpscale(outwidth=960, DARout=4.0/3.0)
or

Code:
SimpleSlugUpscale(outheight=720, DARout=4.0/3.0)
or just

Code:
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

Code:
SimpleSlugUpscale(size="720pbox")
Robert Martens is offline   Reply With Quote
Old 16th October 2011, 15:35   #40  |  Link
nhope
partially-informed layman
 
Join Date: Jan 2002
Location: Bangkok, Thailand
Posts: 314
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 is offline   Reply With Quote
Reply

Tags
qtgmc, resize, tempgaussmc, upscale

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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

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

Forum Jump


All times are GMT +1. The time now is 20:45.


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