Ok, with the same settings you see above I did this night a full encode at quality=94, cause I was just too lazy to do keep doing prediction and the 1% sample was good at quality 94.

And I did let it run. Now I woke up and looked for the archieved end-filesize.

568 MB! That means even enough space to add a second audio channel on one CD-R80.

Now lets see. In fast moving parts there's still the problem with that uneasy "look", at very dark gray parts there do happen also some "stairs" as you also can see in some sample above.

But in the average its phantastic.:

This one here is posted 2x scaled (in words 2 times scaled)

http://www.digitalfaq.com/archives/error.gif

And here another one, NOT scaled, said just at 480x576

http://www.digitalfaq.com/archives/error.gif

I did use a GOP of 84 with a B frame count of 3 means IBBBPBBBPBBBP...etc.

I'm using mpeg2, latest VDubMod. I've done the first pass with defining the stats output file. Afterwards i've changed to 2-pass and set another output file.

@inc:
Nice Results :D 8O
This will rock :!:

Damnnnnn....&%§&/§!"&§%%§/* :evil:

I tried to mux this morning that baby and some errors of (I cant exactly remember right now, cuase I had to left my house this morning fast) ... underflow or overflow....... using BBmpg. TmpgEnc after Muxing also reports that and says "this file may will not play correctly" or something like that. grrrrrrrr. It can't be the GOP as I did already many encodings using that one in TmpgEnc. And I never had such muxing errors before in my life, so thats totally new for me!

I think this evening I have to check the whole settings of mpeg2 ffvfw engine. In the www you can't find any explanation of all these options in every window. :cry:


BTW: I did use on all these encodings a simple light filtering static script! So maybe MA can avoid these "crispy"/Blocky fast moving scenes and as we know Blockbuster can do something against these "stairs" in dark grey surfaces.

So this is just the beginning. I'm not full enthusiasted right now, but really impressed! :D

:!: :!: :!:

I didn't have the time to do any encoding yesterday so I just look at all the samples here but... ffvfw is 50% SLOWER than tmpgenc ?
That means that you need 12-18h to make a Movie ?
(tmpgenc takes me 8-10 h for a KDVD - CCE 4 hours !)

Well according to speed incl just a light avisynth filtering ...
(Asharp(1,4).stmedianfilter(3,3,0,0).Temporalsofte n(2,3,5,15,2))

at 480x576:

- ffvfw encodes ca. 22 Frames per second

- CCE factor 1.4

- TmpgEnc takes almost the same time like ffvfw, so there is (at my machine) no difference.

To Kwag.
I don't have reply from Milan :( And you :?:

Heya guys,
Ok, about speed comparison between tmpgenc and ffvfw with pc specs as you can see in my signature
I encode 4-5fps in tmpg and 2 in ffvfw. I don't compare to cce because of the amount of $ or € it costs :wink:
I know where not here for speed otherwise we wouldn't use some of the tools we do, but it would be nice
to make speed even on both tmpg and ffvfw.
Anyway, I'm droping tmpg because I only do MPEG2 for KDVD and ffvfw is looking better than tmpg.
I did all my speed/quality tests using kwag's settings for ffvfw and using kwag's MA script
with Incredible's Slicer() function.
I'll try to get home early and test tmpg/ffvfw with MA without slicer and with MA without GripFit
and compare final speed/quality.
Cheers

What is funny is that everyone will tell you are right but noone use vaguedenoiser despite its quality. Guess why ? :-D

You can use ffvfw also with tmpgenc. No need to use vdub for that. Perhaps the problems with 2 pass will be ok (just an idea).

It's the same idea of what i think this morning, Dialhot. Only i don't know how to encode AVIs with TMPG.

SImply do everything as you always did and go to file menu, then choose "ouput to file" then "avi file".
There you can choose the codec and I guess that ffvfw will be in the list.

Note: tmpgenc can either output in wav (for people converting avi and using vdub for extracting the audio).

I followed this thread at home last night.

See if I get this

Open your avs in vdubmod.
Select full compression, ffvfw codec.
Make all adjustments kwag showed before.
In output choose store frames to external file
Ex. E:\test.mpg
close codec window
Then what.

Save as E:\test.mpg?????

I get "An error occurred when video was encoded" with TMPG in way you described Dialhot. Maybe TMPG can't produce fake avi files.

And for speed test:
ffvfw MPEG2 ~7min Q100
TMPG MPEG1 5:40 min Q75 (KVCDx3 template with 740x480 res)
same sample size with avs script only as parser for d2v file.

Edit: ffvfw MPEG1 is 10% slower than TMPG, but in fact this is not result for me. Speed depends form Qfactor. My first test (just for result of file not quality) was in Q40, and it was almost two times faster than TMPG. This results are with Q100. So since speed very depends on Q value, i don't se arbitral procedure to test speed one vs another.

Hi Phil,
I was just wondering...
Would tmpg be better than vdubmod? Just theoretically speaking.
I'll have time to try this but it was just a thought.
Also I think we should take a look at ffvfw's presets.
Don't know if u guys are using it. I am.
Since I'm at work I can't see if these are text based or binary based but should they be text based I think
we should start posting it so everybody knows what options were used for encoding :wink:
Maybe the German/French guys get home a bit earlier than us can investigate the presets and tell us :wink:
Cheers

Better perhaps not espacially in resizing, if you plan to not use an avs script to do that). But a lot of people here never did avi and so do not even know the GUI of virtualdub. But they know for a long time the one of tmpgen. That's why I mentioned that point (I have to check at home why it doesn't work).

Maybe we should generate two Threads, one for speed improvement and another for quality reports/testings :idea: :?: :wink:

If the tests of rds_correia are right, speed and quality are tied together.
Will this thread beat the record of "CQ vs CQ_VBR" one ? :-)

Sure hope so :lol:

@Inc.
I am inclined to agree with phil about the quality/speed being tied together at least until proves it wrong.
So I wouldn't find it a good idea to split to 2 threads at least right now.
I still think that Mencoder results were almost as good as ffvfw but A LOT faster than ffvfw :roll:
If we could just convince those guys to implement avs support in it...
That would REALLY blow tmpg/cce/mce out of the skies.
Cheers
PS-Any thoughts about presets??

YEP, but we should first get this baby to work in the whole range of movietreatment well! So stills and less movement as you see in my samples are no problem but the fast moving scenes can't beat TmpgEnc/CCE (even using that high "quality"-factor in ffvfw), thats my conclusion today after trying the whole evening yesterday.

And if it will work continuosly well on every part of the VBR dynamics, than we can screw on other settings to archieve better speed.
Cause what should I do with an encoder which is fast, but the quality is worse than TmpgEnc.

My example above which takes a GOP lenght of 84 and a IBBBPBBBPBBBP sequence where 3 B frames are used (IBBBP), so it takes longer, as the encoding of B frames is more complex due the encoders algorythm to do BI-directional refering encoding, means "watching" afterwards AND forwards and comparing, where P frames only do refer predictiuos - in one direction = more B frames mean more encoding time! And thats why I wanted to get rid of that IPPPPPPPPPPP (only P frame) issue as by this the frames from one I frame to the next will get worse and worse. (you know that Phil but I wanted to discover just only 1 aspect of speed-problems in here to all participants)

Presets?

Well do set everything as showed in the screenies of Kwag, exept playing with GOPs .... where I did that max I frames = 84 and min I frames = 1, do also play with the quantizer values as also explained by me some postings above. But that GOP thing as I tested above is NOT DVD compilant and was just for testing the behaviour of the encoder on that!

BUT I'm still there with that muxing afterwards-problem as these over/underflows did occur :!: :!: :!:
(But as I know myself very well I just did run too fast and its just a thing of setting al little option in ffvfw right - and then I gonna HIT MY HEAD, as always! :banghead:

Don't worry, I do not personally search speed for itself. I did a remark about speed because these days I have the time to do a quarter of what I would want (even without sleeping ;-)). So I'm not sure I will find the time to participate to this thread if the encoder is soooooooo slow :-)

PS: I know, I can overclock my CPU :-D