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

You should better "overclock" your other activities this week which do steal your time and do keep you away from 24h testings on this here! :lol:

5 postings more and I receive my first golden watch from Kwag :lol:

@ All others:

Noone else posting pic samples in here???? Come on! We want to see results from diff. users and their success or failures which could enlighten some more possibilities :!:

Hi Inc,

Yesterday, I was also trying a GOP structure of IBBBP (3 B frames), and I think the results are better than with 2 B frames. Still to be confirmed, but I think this CODEC does produce better quality and compression!, with a 3 B frames.

-kwag

Hello everyone!

I just found this thread and I am very impressed by the screenshots and samples... If this gives such good results, maybe then it could replace CCE in D.I.K.O. as a option for MPEG2 encoding. Or maybe for real-time KDVD encoding, this would be great too (I always wanted to do that and MainConcept does not work as it should... And I won't even mention the other options). I am starting my own tests right now. (My vacation is getting over... I have to enjoy the last days!) :D I'll post if I find anything interesting.

Same here.

-kwag

No, not yet.

-kwag

Save as AVI, and that will start the encode.
The end result is "test.mpg", which you have to demux with TMPEG, run pulldown.exe on the .m2v (which creates "pulldown.m2v"), run DVDPatcher to fix the reporting bitrate, and mux with your 48Khz encoded audio.

-kwag

At this pace, maybe :lol:

-kwag

So you do als confirm like me that its better to use 3 Bframes in ffvfw mpeg2? Cause of the "but" in your line above.

At now I still can participate indirectly as Im at my MAC in the Office.

ok. more B Frames do give more compression in case of ffvfw mpeg2, but still we have to solve that problem on dark fading surfaces and also the fast movement-part issue. The last one "could" be solved (if its not possible within ffvfw) by MA, but this only will affect frames with full movement and where blur does not harm quality. But whats about "parts" in static frames where in case of movement that ffvfw mpeg2 comes out crispy/blocky ... well we'll see tonight! mabye... ;-)
And to me it seems that the encoder handles the DCT matrix different compared to TmpgEnc or CCE.
That "crispy-fast movement-encoded-frames" phenomenom I still remember from FFmpegX where its encoding engine in 2002/03 also did base on mpeg2enc's algorythm, maybe still it also optionally bases on mpeg2enc.

Kwag, any suggestions on my muxing problem?

Hi Kwag,
Don't have the slightest idea of what is pulldown.exe and what it does to the video stream.
Could you enlighten me on that please?
Is it only for NTSC or do PAL guys need it too?
Thanks and C ya all at page 8 :lol:

@rds_correia
Pulldown is only for NTSC. There is a utility called pulldown.exe that can be found on doom9 software page. This utility enables a pulldown flag in 23.976 FPS mpeg2 files, what makes the DVD player "create" 29.97 out of 23.976 fps to play on a NTSC TV.

@all
Encoding can go a little faster (jumps from 8 to 9 fps for me) using Fast Recompress instead of full processing mode in VirtualDub.

Yes I can, "but" at a very slight file size iincrease (about 300KB per minute)
So that's about 18MB per hour. So for KDVDs, that's fine. For KVCDs, NO :!: Shame on you. :lol: I still think this is a PAL issue, because my encodes are less blocky than with TMPEG. Yes it does. As I said before, it's a completely different motion estimation algo. There are barely any visible artifacts around objects, even on low bitrate scenes. I think the encoder is not going up high enough in bitrate. I've tried to change settings, but can't get it to work at high bitrates. Even setting MIN and MAX quality to "2" and macroblocks to 2/2.Can't say :!:
I just finished muxing "The Bourne Identity" with MPlex, after running pulldown.exe and DVDpatcher, and it muxed without any errors. This is the second movie I've encoded with this CODEC since yerterday, and the result is flawless. But you know I'm on NTSC, so maybe that's why I don't get errors (or blockier picture :!: ).

-kwag

As far as I know, there is only two diff between NTSC and PAL : the framerate and the resolution.
For the resolution we can't do anything. But if the problem is in the framerate, you can try to encode with a "AssumeFPS(23.976)" in the script and as you are in DVDPatcher, set back the fps to 25.
This way the encoder will be fooled and think it encodes NTSC but the player will see a regular PAL to play (remember to use a valid PAL resolution).

In my case the opposite as you see above, in general I got less filesize and therefore more compression + Quality with 3 B frames :arrow: must be the colder weather in germany ;-)
Well as I tested it also on 23.976 encodings, therefore same in NTSC as in PAL, ...... BUT we'll see this evening more, I hope you all will be online. ;-)

Exactly that I did Dialhot, Assuming the FPS to 23.976, resizing to NTSC specs. and did several encodings.

Ähm ... are you shure your workout above with simple mpeg patching will restore the playback speed afterwards? I don't think so.
That would mean you just take a 23.976 enoded DVD m2v - doing the FPS patching - pitching the audio to 25fps - burn ;-)

How can a player know the framerate to use if it is not by reading it in the header ?
The video stream by itself do not contains information about the speed you have to read the information. That is the purpose of the header !
No ?
I said taht there are two differences :-)
You can't do that because of the resolution.

Well (generally) the header does not provide everything, also many thing are in the encode itself, thats why a Pulldown flag with pulldown.exe won't be applied just in the header as Pulldown.exe rewrites (not reencodes) the specs. in the whole stream .... and thats I think not only a thing of seq headers. Also the 23.976 to 25 (patching) won't correspond good with the timestamps(timeline) in the mpeg stream as that you also can set in CCE for example, .... but that are all estimations, ... so we should check this out .... cause I've never heard about such a patching method elsewhere :)

EDIT: in my Cyberhome Player the resolution won't be a problem as its also be able to play back 480x480 or 704x480 streams at 25 FPS ;-)

I was thinking about distort on the TV set. How is the image on your TV when you do such things ?

Just did my tests. I got a 3m04s chapter from the Lawnmover Man DVD and encoded with the latest MA script at 704x480 using:
- FFVFW - quality 100, Max quantizer 25, B frames 2, KVCD notch matrix, I frame interval (GOP) 18. Using Fast Recompress. Size: 33.504 kb.
- CCE - my 704x480 template, also using kvcd Notch, at Q40: 33.353 kb.

Both encodes took about 8 minutes, what surprised me a lot, since I espected FFVW to be a lot slower.

I tried to used the script below to find any difference in quality, scanning frame by frame:

c=mpeg2source("test_ffvw.d2v")
d=mpeg2source("test_cce.d2v")
return(stackhorizontal(c,d))

But nothing called my attention in respect of quality. So I decided to use SSIM (http://forum.doom9.org/showthread.php?threadid=61128), which is a avisynth filter that computes the quality metric, based on perceived distortion and not only on mathematics. According to the author, it should correlate very well with the human eye. This filter receives two clips as input (the original and the encoded) and gives a table with the coeficients for every scene and a median of all of them.

To compare, I create a huffyuv version of the chapter, already processed by the MA script.

The results were very surprising. The final value is between 0 and 100, and the bigger the value, the great the quality. Check this:

CCE:
SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 55.22

FFVFW:
SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 83.64

It' scary how better FFVFW performed agains CCE according to SSIM. I'll tried to create the same clip with TMPGENC but forgot to change the template and did it at 720x480. But I'll do it again and post the results. To me, looks like this is THE encoder for MPEG2. :D

@ Phil

Well the cyberhome to me seems that he just simply reads out of the Header the Aspectratio and increases whatever he gets to the pal 704x576 which will be delivered to the Tv Set.

Ok, as NTSC doesn't got that much pixelinformation/resolution like PAL, it doesn't look that detailed, because its resized to 704x576.

But motion is smooth and appears ok, but I do not see that advantag to go from 480x576 to 480x480 both 25FPS. Maybe 480x480 will give a little more CQ but on the other side it has to be stretched afterwards :arrow: the more little artifacts cause of less size and therefore more CQ will be again scaled afterwards and sometimes do look if you would have directly encode that at less CQ from 480x576 but its not that sharp!. Ok, it depends of the Tv Set quality.

For those of you looking for more speed the 20039027 build is faster.

Hey Kwag, I don't know about Milan but I do know Athos (he did the more recent builds) is active at doom9. Cheers. :D

Not scary at all :D
It confirms what my eyes have been seeing in the clips I've been encoding ;)

-kwag