AviSynth resize vs GripFit?
Anyone else noticed that it is way faster to encode with the internal resizing methods in AviSynth, versus using the YV12 version of GripFit. Encodings that before took 3,5 hour to finish, are now over an hour faster when not using GripFit.
|
As Gripfit simply calls internal avs resizing function, the speed is the same for both methods.
(see "resizer" parameter in gripcrop and its use in the code : it's simply a "function pointer", that means a direct call to the original function). You surely did other thing that slow down your speed (use a convertToYV12() in one case and notin the other preharps ?). |
Nope, not doing any conversions. I'm really seeing a difference here in speed. Here's my scripts with and without GripFit.
Code:
## DLL Section ## Code:
## DLL Section ## |
Another thing: Sometimes using GripFit with certain movies causes AviSynth to crash with an error. Especially when running a prediction with Tok. Haven't happened yet using AviSynth resizing.
|
Maybe GripFit has a function call overhead before it calls the internal resizer, which is not the case when calling BilinearResize directly :!:
Probably on very fast machines, this is not so visible. But on slower machines, it is :idea: I'll have to run a couple of tests to verify this. -kwag |
Sorry but there is a big difference between the two scripts !
The source is an avi, so definetly not anamorphic. Gripfit is used without the parameter "source_anamorphic=false" and thinks it is anamorphic (the default). The image area won't be the same in the two methods, and there is were the speed difference is, I think. Nismo, make a test with "source_anamorphic=false" and give us the result please. |
I'll do some more testing later when I get home from work.
|
Ok, just tested with the "source_anamorphic=false" option, but no change in encoding speed. Even tried with a DVD rip, and AviSynth resize is still much faster. Weird.... No one else tested this?
|
Hi NismoSX,
What processor do you have :?: ( CPU?, CPU speed? ) -kwag |
AMD XP 2000, VIA KT400 chipset, 256 MB PC2700
Should be fast enough. :wink: |
Quote:
But then, maybe GripFit is not optimized to use Athlon's instructions as a P4 using SSE-2, etc. :idea: So on every frame, GripFit functions are called, which then call BilinearResize functions, and there is the small delay. When added up to the sum of thousands of frames, that could be the reason for the time difference. -kwag |
I think it must have something to do with the YV12 version of GripFit. Didn't have this big speed difference before when I was using the old AVS 2.0x script. And I've encoded well over 100 films with that script. :)
Now for instance, if doing a file prediction with ToK using GripFit is taking 15 minutes, the same prediction without GripFit is only taking 7-8 minutes. |
Quote:
-kwag |
Already done it, for now anyway... :)
Maybe there will be a bugfree GripFit_YV12 version in the future... |
Quote:
|
Holly crap, SansGrip we haven't heard from you in a while. Nice to see you again (and I think I speak for everyone).
|
Quote:
Do kvcd 2 cd movies look ok on the HD tv? I've been putting all my movies onto two cds and they look great on my 27" standard tv (i'm poor :roll: ) Others here have said though that they look great on their HDTVs. Well maybe by the time I get an hdtv I'll also have a dvd burner and I'll be 79 yrs old :lol: ren |
Hey, SansGrip showed up :lol:
Glad to see you around :cool: Take a look at the new Motion Adaptive script :idea: Most of my KVCDx3 encodes look sweet on my HDTV, when processed through that script :mrgreen: -kwag |
Quote:
|
Quote:
Quote:
Quote:
|
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.