View Full Version : 2.5.1 SpeedUp - 3x slower


zyrill
19th March 2003, 17:31
:scared:
i don't know what happened! i did everything like always, i use following script:

LoadPlugin("MPEG2DEC3.DLL")
MPEG2Source("Die Hard.d2v",cpu=6,iDCT=-4,iPP=false)
Crop(4,70,714,436)
LanczosResize(716,306)

And i have a cool fps like this: 8 fps!!! 1 pass takes 7 hours!!! i'm really MAD!!!

lol it's so weird following script has the same fps:

SetMemoryMax(256)
LoadPlugin("MPEG2DEC3.DLL")
LoadPlugin("Decomb.dll")
LoadPlugin("Convolution3dYV12.dll")
MPEG2Source("ESB.d2v",cpu=6,iDCT=-4,iPP=true)
Crop(12,106,700,276)
LumaFilter(-15,0.9)
Telecide(chroma=true,threshold=1,dthreshold=1,show=false)
Decimate(mode=3,cycle=5,threshold=0.1,show=false,quality=3)
Convolution3d(0,3,4,3,4,3,0)

could anyone give me a clue how to solve my problem: to all ye coders: can i give you some logs, dumps or something else? i'm totally confused...

DJ Bobo
19th March 2003, 18:04
It doesn't have necessarely something to do with your speed problem, but it's worth mentioning: what the hell is that:

Crop(4,70,714,436)
LanczosResize(716,306)

If you can't have 720 because of black bars, go all the way down to 704! (and not crop to 714 then resize up to 716, this is the weirdest thing I've ever seen!!)
And what's that 306 of yours?! it is not div16, so you're better off with 304.

So better make:

crop(8,70,704,436)
BilinearResize(704,304)

bilinear because you'll be resizing in only one direction, so it is fully sufficient.

sh0dan
19th March 2003, 18:08
Are you using latest VirtualDubMod? Did you remember "Fast Recompress"?

What's your destination?



(thread title and post moderated - please use a better language - even if you're mad!)

zyrill
19th March 2003, 21:37
Originally posted by DJ Bobo
It doesn't have necessarely something to do with your speed problem, but it's worth mentioning: what the hell is that:

Crop(4,70,714,436)
LanczosResize(716,306)

If you can't have 720 because of black bars, go all the way down to 704! (and not crop to 714 then resize up to 716, this is the weirdest thing I've ever seen!!)
And what's that 306 of yours?! it is not div16, so you're better off with 304.

So better make:

crop(8,70,704,436)
BilinearResize(704,304)

bilinear because you'll be resizing in only one direction, so it is fully sufficient.

why should i go down to 704? what's the use? i crop the black bars away and then resize to the next best x mod 4 = 0... and in that case it happens to be 16! why should i crop away more picture than i want to? why lose actual film-info??? THAT'S the weirdest thing i have ever seen! and who cares if the height is dividable by 16??? the codec accepts everything dividable by 2... so same as before - i choose the ratio at which i have to change the AR the least! i happen to do everything manually and i happen to computer my aspect ratio myself because it's much mor exact. that's why i have 716,306... i don't understand why i should do what you suggest!



Originally posted by sh0dan
Are you using latest VirtualDubMod? Did you remember "Fast Recompress"?

What's your destination?

(thread title and post moderated - please use a better language - even if you're mad!)

Sorry for my crude and inapropriate langue - won't happen again :rolleyes:
yes, of course i used Fast Recompress... and i'm using normal VirtualDub btw.... do i HAVE to use the mod? because i recall encoding with normal virtualdub and fps of somewhat like 20... i'm encoding to DivX 5.03.

sh0dan
19th March 2003, 22:14
You HAVE to use vdubmod to get YV12 encoding - otherwise the video will be converted twice.

In general it is recommended to use mod-16 for output. It is faster, and it will actually produce smaller output files. There has been tests in the DivX / XviD forum you should be able to find using search. Also most hardware has problems if the video width/height isn't divideable by 16.

DJ Bobo
19th March 2003, 23:07
Originally posted by zyrill
why lose actual film-info???

Don't make me laugh! hit me if you notice that 10 vertical lines are missing while watching your movie :p

zyrill
20th March 2003, 12:37
pffff.... why don't you delete 10 lines at EVERY corner? compressibility gain about +20% and since you don't notice it anyway it's completely without disadvantage...

zyrill
20th March 2003, 12:39
Originally posted by sh0dan
You HAVE to use vdubmod to get YV12 encoding - otherwise the video will be converted twice.

In general it is recommended to use mod-16 for output. It is faster, and it will actually produce smaller output files. There has been tests in the DivX / XviD forum you should be able to find using search. Also most hardware has problems if the video width/height isn't divideable by 16.

thanks for pointing that out! but i think i'll stick with mod 2 respectively mod 4 since i don't care if 3 seconds of the credits are missing but i do care a lot when i notice heads that are egg-shaped - and i'm very sensitive about it.

N_F
20th March 2003, 12:59
@Zyrill

I think you misunderstand DJ Bobo. He's suggesting that you resize down to 704, not crop which is what you seem to imply.

Edit: Also, do you really think you would notice an AR error of ~0.5%?! Perhaps it's just me, but unless I use a ruler I can't really tell if a movie was encoded at 0% AR error or 5%. The player you use may also do some tricks to your AR...

N_F
20th March 2003, 13:06
@DJ Bobo

You mention something about resizing in only one direction and I think I've seen this on several other occasions. I always assumed this meant that you only resize in vertical or horizontal, not both at the same time, but I'm not so sure anymore... wanna enlighten me?

Acaila
20th March 2003, 13:23
@zyrill:
the codec accepts everything dividable by 2Yes, according to DivX their codec does support everything down to MOD 2, however there have been a lot of reports of people experiencing bugs when they actually use this kind of resolution. GMC and QPel in particular sometimes choke on videos that are not at least MOD 8. That's why it's much safer not to use MOD 2/4, unless you screen every encoded video thoroughly for bugs.

Also, various Avisynth filters don't support MOD 2/4 material (Dust is one that comes to mind).

MPEG2Source("Die Hard.d2v",cpu=6,iDCT=-4,iPP=false)Using iDCT 4 is really not necessary, nobody can even see the difference between 32 and 64 bit, let alone between 64 and IEEE reference. If you want speed, use 32 bit (setting 2), if you want quality use 64 bit (setting 3). If you want to slow down encoding without getting any visible increase in quality then by all means use setting 4.
Besides, I don't know if setting these in Avisynth is the same as setting them in DVD2AVI, but the IEEE reference in DVD2AVI doesn't work correctly. So unless Marc manually fixed it in his filter, this one won't be correct either.

@N_F:
Yes, resizing in one direction is either:
- resize horizontally, keeping the vertical intact
- resize vertically, keeping the horizontal intact
Theoretically Bilinear is sufficient when resizing in only one direction, but I must admit that I never use Bilinear myself, even on an occasion as that.

Boulder
20th March 2003, 16:43
Originally posted by zyrill

MPEG2Source("Die Hard.d2v",cpu=6,iDCT=-4,iPP=false)


What's this -4 as the iDCT value? Shouldn't it be just plain 4 without a minus?

zyrill
21st March 2003, 16:44
Well, matter of factly i do screen every encoded movie for errors - and i notice aspect ratios even as small as that... it might be uncommon but when a ball is rolling over the screen and it's not perfectly round i get a "feeling" :p
Speaking of slow performance: 15 or 18 fps as i get it when using the script i posted above is completely okay with me - and even if i might not notice it, i feel better when using the highest possible quality modes there are around... it's like listening to vinyl on a poor stereo - it's still cooler, somehow ;)