VirtualDub won't open upconv=true and info=true?

[animegirl909]

Exactly what the title says.

I was trying to compress my script with the Lagarith codec, but it wouldn't let me - I get this message saying:

Code: Select all

Avisynth open failure:
script error: the name argument "upconv" to mpeg2source had the wrong type

I deleted the upconv tag, but then I got a message saying:

Code: Select all

Avisynth open failure:
script error: the name argument "info" to mpeg2source had the wrong type

This is my script. I'm using the American Fruits Basket DVDs.

Code: Select all

mpeg2source("C:\Users\Yiwei\Videos\Fruits Basket\MainMovie\D2V Files\furuba1-1.d2v",cpu=4,upconv=true,info=true)
AMVIVTC(mode=1) 
Crop(8,0,-8,-0)
Spline36Resize(640,480) 

Thanks for your time. :]

[mirkosp]

I don't think you really need the upconv or the info parameters. And you probably don't need the cpu=4 either (really, leave the cpu parameter out, it's the best thing for most sources).
Either way, if you do need upconv and info for some reason, according to the dgdecode user manual they are int variables, not bool. They might have been changed some version ago, I guess. Specifically, here are the values:

upConv: 0 to 2 (default: 0)

Upsample from 4:2:0 to YUY2 (4:2:2) or RGB24.
- 0: Do not upsample
- 1: Upsample to YUY2 (ignored if input is already 4:2:2)
- 2: Upsample to RGB24

info: 0 to 3 (default: 0)

Debug Information.
- 0: Do not generate debug information
- 1: Overlay debug information on the video
- 2: Output debug information via OutputDebugString()
- 3: Output hints in the video (as defined in utilities.cpp/utilities.h)

I'd say you really really really don't want to use upconv (avoid colorspace conversion when you can avoid them). Info you might need for some reason though, I guess, so see which option is the one you need.

[animegirl909]

Oh I see, thanks so much! :3
I kept the CPU in because in the guide, it says that 5 and up mess up the video, but 4 keeps it smooth and clean, or something.

I'll leave it out though, it means less confusion for me! Thank you. :]

[mirkosp]

Yeah, that is one of the thing in the guide that should be rectified... not everything in the avtech can be taken as gold unfortunately.

[Qyot27]

Rather, it's that while the guide has updated itself in terms of recommended software (i.e. x264), the filtering recs are still largely from the XviD era, in addition to quite a lot of sources then not being authored very well, or using poorer 'master' copies to start with.

People often forget how big of a deal the 10 MB/minute 'standard' for SD content was, and to make XviD get to that, it means doing more aggressive filtering and smoothing than H.264 as a collective standard does, even more so when it comes to the progress made with x264 (--mb-tree and --weight-p will literally make you shit bricks compared to revisions of it before those were introduced). Just look at how common -toon variants and warpsharping things to the Moon and back were then - although I always hated how that looked and tended to stay away from such excessive filtering, even if it meant tacking on an additional 5-15 MBs to my filesizes. It looked like the stuff was filmed in a fishbowl sometimes.

The switch to H.264 made the filtering question largely irrelevant, and the trend toward releasing material in HD - and even full 848x480 for 16:9 SD content, instead of 768x432, 704x396, or 640x352 - blew the 10MB/min. thing out of the water (aside from it being mindnumbingly-easy to hit or skirt beneath that mark with the way x264 is now).

[Scintilla]

(--mb-tree and --weight-p will literally make you shit bricks compared to revisions of it before those were introduced).

... Remind me to stay away from those options then, because that sounds painful.

[Mister Hatt]

This thread is some surefine proof that nobody in the AMV community has any idea what they are talking about, :AWESOME:

Re dgdecode: don't use upconv, cpu, or info arguments. Ever.
Re avtech3: don't actually use any of the examples in it. Ever.
Re XviD: it actually has the same issues as x264 for he most part only everyone is too dumb to realise this.
Re x264: mbtree/weightp still sucks nuts on pretty much everything unless you allocate bitrate manually (anyone remember DivX before SBC was introduced?) or use some fancy patches.
Re filtering: you're all blind and have no idea what defects are in your source nor how to best fix them, so don't filter unless you have to. You don't have to.
Re Scintilla: RTFS and then beamlaugh rainbows at how sugoi fucking nais x264 is now.

[mirkosp]

Re Scintilla: RTFS and then beamlaugh rainbows at how sugoi fucking nais x264 is now.

He was just trying to joke, it's not his fault if he's bad at it.

[Mister Hatt]

I was too but you missed it. Poor form mirko, poor form indeed.

[Scintilla]

Re Scintilla: RTFS and then beamlaugh rainbows at how sugoi fucking nais x264 is now.

He was just trying to joke, it's not his fault if he's bad at it.

So misuse of the word "literally" is a pet peeve of mine, so sue me.