AviSynth problems

[phinsman]

Hello all...

I just started using AviSynth two weeks ago and am hooked on it. Now I can't go back to my old frameserving methods.

Yesterday I reinstalled Windows 2000 on my computer. I've done it many times and of course am good about reinstalling service packs and such.

All of a sudden AviSynth doesn't work for me anymore. I'm using the same settings as before with my capture program, 720X480, MJPEG quality 19, etc.

When I try to load even very simple scripts in Zoom player, which worked before, I get Access Violation errors.

I can live with that. However, I can't make TMPGenc read the scripts either, and when I thought I had successfully encoded with CCE, the video was not resized as I specified. Here is the script:

AviSource("y:\1.avi") + AviSource("y:\2.avi")
Trim(5525,8118) + Trim(9928,27682) + Trim(31003,32247) + Trim(34991,46690) + Trim(50012,59287) + Trim(62576,63677) + Trim(67021,72065)
HorizontalReduceBy2()
Crop(4,0,352,480)
Letterbox(0,8)

With this script, the trimming worked; the resulting MPEG had the correct frames in it. However, it was not resized to 352X480 as I specified. The MPEG was actually 640X480. This is the same script I've been using for a couple of weeks so I know it works.

I currently have version 2.52 installed. I also tried 2.08.

One more thing...when I use the simple one-line script:

Version()

That will load in Zoom Player correctly.

I'm stumped.

There's something else I forgot to mention: my scripts work fine in VirtualDub, and they are even resized properly.

Thanks to all,
Dale

[phinsman]

OK I was wrong on some things.

The resulting MPEG actually IS 352X480. Zoom Player was lying. Apparently most of my problems are with it. I've used it before for this kind of thing so I trusted it.

I guess the only thing I have to solve now is getting TMPGenc to read the AVS scripts. I do have the VFAPI plugin installed.

Oh well, sorry for the confusion.

Dale

[stickboy]

Are you using the latest version of Tmpgenc?

IIRC, older versions needed RGB input.

[phinsman]

Originally posted by stickboy
Are you using the latest version of Tmpgenc?

IIRC, older versions needed RGB input.

I'm using 2.58. Anyway, it worked before so I'm not sure what I'm doing wrong now.

Thanks,
Dale

[Wilbert]

Did you try everything in Q2.4 (http://www.avisynth.org/index.php?page=Section+2%3A+AviSynth+and+frameserving#q2.4)?

[phinsman]

Thanks guys.

I finally listened to you both. The first thing I tried in Q 2.4 was ConvertToRGB24 and now TMPGenc reads the scriptss.

Question though...well this add a lot of time to encoding?

Also...why did I have to do this? I'm pretty sure I was using the same version before and didn't have to do this.

Dale

[sh0dan]

It won't add to encoding time, as TMPGEnc always reads RGB24.

It would be faster if it read YUY2/YV12 or even RGB32, but since it doesn't, the conversion would be done elsewhere anyway (in a DShow/VFW codec).

[phinsman]

If not an increase in encoding time, does it take longer, and significantly so, since AviSynth will be converting to RGB24?

Dale

[scmccarthy]

Stickboy said that TMPG no longer needs RGB24 as input, but that is not true, is it? It seems more likely that the conversion is taking place elsewhere (DirctShow/VFW) as Sh0dan suggests.

Stephen

[stickboy]

I'm probably mistaken. I remember having to convert to RGB24 on my system before, but when I tried it with a YUY2 source last night, it seemed to work fine.

[DDogg]

As mentioned several places and assuming you have huffy installed, this should allow you to never need the converttorgb24() statement with TMPG:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"VIDC.YUY2"="huffyuv.dll"

[scmccarthy]

@stickboy

I'm probably mistaken. I remember having to convert to RGB24 on my system before, but when I tried it with a YUY2 source last night, it seemed to work fine.
The conversion taking place "elsewhere" means that TMPG still requests RGB24, but you don't have to include it in the avs file via the ConvertToRGB24() statement.

Problems occur when your system changes and suddenly the conversion does not happen automatically anymore. At least I think that could happen.

I believe what Sh0dan said above is that when you add the statement in the avs file, it shouldn't slow down the encode, because the conversion to RGB24 when you use TMPG is happening regardless.

So even if you successfully configure your system as Ddogg suggests, it probubly won't speed up your encodes.

@Ddogg

Does huffyuv.dll now work with both AviSynth 2.08 and 2.52?

Stephen

[phinsman]

Originally posted by DDogg
As mentioned several places and assuming you have huffy installed, this should allow you to never need the converttorgb24() statement with TMPG:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"VIDC.YUY2"="huffyuv.dll"

Yes!

That did the trick. I did have huffy installed but didn't know about the registry entry.

I looked in my registry and the VIDC.YUY2 was set to something like msyuv.dll. I changed it there and everything is fine now.

Thanks very much.

Dale

[scmccarthy]

@phinsman

The huffyuy2.dll does the conversion to RGB24 for you automatically, instead of having avisynth do it, right? It may be more convenient, but chances are it won't increase the quality or speed of the encode.

Stephen

[DDogg]

scmccarthy, that is interesting now that you bring it up. Using Huffy is something I "have always done" when using TMPG to avoid the converttorgb24() statement. Given all the work Sh0dan has done increasing the speed and accuracy of colorspace conversion in Avisynth 2.5x, I wonder if it might be a good idea for tmpg users to try both and directly compare results before doing that reg tweak.

Sh0dan, if you check this thread, do you have an opinion on what method would be the fastest or highest quality?

[lordkinbote]

I tried the reg tweak and it didn't work for me. In fact, I also tried changing all of the vidc entries that were assigned to msyuv.dll to huffyuv.dll and that still didn't work. I have to still add the ConvertToRGB24() to my avs.:mad: I was hoping I could find a solution that wouldn't make me have to edit the avs.