ffdshow is the decoding part only of the codec (coder/decoder) called ffvfw
I never said they are tied together, they are TWO COMPLETLY SEPARATED PROGRAMS using the same code. But one is used by the system as a directshowfilter (and can't be used by avisynth for instance if you don't use directshowsource), the second one is referenced as a codec under VFW API of windows.

The same way you can find directshow filter part only of Xvid codec. If oyu isntall only this part, you won't be abble to do any xvid with avisynth as it will said "no codec found for this source".

One more time CODEC and DSHOW FILTER is not the same thing

That's strange. It hasn't bombed on me, not even once Haven't had a problem with that either. I don't get any under or over flows. No, there is not. However, if you can find one of the early beta version of TMPEG, TMPGEnc-0.11.20.97.zip with the english patch, there's an option in the MPEG tools that will let you correct the VBV buffer size. Give that a try.

-kwag

@All
Don't seem to be following you guys (Kwag/Inc).
Is there a problem with a vbv buffer being so low or not?
Because I should be experiencing muxing problems also (since I'm PAL also) and from a small 5 minutes
clip I did today with ffvfw and headac3he muxing with both mplex and bbmpeg gave me no
under or over flow errors at all.
If I wouldn't want to use VdubMod would there be any other app I could use instead?
@Kwag / Hydeus
Any news from Milan yet?
Do you still need to talk with him?
Would documentation help us here?
I hate when somebody suddenly disapears from the net...like Muaddib and Jorel...
Cheers

__________________
Rui

Hi all,
hey incredible, I also didn't run in those problems ever. I don't know if it's a matter of size (you said 352x576). Maybe this codec, the less the resolution, the less the max bitrate and less VBV... do you think this is possible?.
I did my tests at least with 528x576 res., and could multiplex with bbMPEG without a trouble (no over nor under flows). Even I fed once TMPGEnc DVD author with a MPEG2 file without patching, and just got a warning, but did create the IFO and VOB files, that played fine in PowerDVD...
I guess that we have to test, test, test, and try different settings (what about changing in Motion Estimation, EPZS estimation to Adaptive?) in order to get the best of this codec. As I don't have idea how to adjust it, I just wait for any suggestion to test it.

I did'nt disapear (few free time, alot of work ). I also have no reply from Milan, but manual is no use for now, however few bugs need to be squash.

@Incredible
I also have this underflow problem with BBmpg in mux, and this files are jerky playable on standalone (when recorded with VCDEasy). Also the same files burned with Nero are perfect. Any idea why??

And for another thing. When setting postprocessing to full in ffdshow (under input/enable image processing) gave me smaler file with the same quality. Please anybody confim or deny. My eyes are subjective.

Edit: On the other hand, encoding is almost twice slower
Edit2: With postpr. and noise, speed increes a litle, but image is litle blured.

__________________
Go for SECAM =)

@Phil,

Sorry I didn't mean to imply that ffdshow was a decoder, just thought you didn't realize ffdshow's preprocessing filters could be accessed ffrom within ffvfw. I see I was wrong.

__________________
-Dano

One question for Kwag or others : I just did a little test with ffvfw and in the end my video doesn't have a constant Q like yours in bitrateviewer.

The value runs from 2.25 to 3.36. Is that because I do not use pulldown (I am doing PAL) ? Or what can be the settings I missed ?

Same in my case! Strange!

You would ask now why my Bitrateviewer doesn't bomb, because in case of small samples it does import it well, but not full long ancoded movies.



Watch the VBV Buffer size and also - although mpeg2 encoding - the (in regular to mpeg1 allocated) LINEAR Quantisation scaling.
(same output when demuxing before!)

Same thing here, and it's not a PAL issue since I am doing NTSC. But picture quality is still great.

Except than my Q curve is more like the yellow one on your snaphop ! In fact both lines look like a montain lansdcape

I just have to reinstall my bitrateviwer as it hung as soon as I click on "open" icon

Mine is also 7 and on the snapshop provided bu Kwag, it was also 7 So that not seem to be a problem.

Hi: Why the Maximmum I frame interval in usual KVCD Template is 24 or 25 (ntsc or pal), and for ffvfw is 18 or 15?

Well my Q curve does look like influated by an intervall, so where do we have an intervall in our encoding: In the max. I framecount and also within the GOP itself. And I think its a issue of different B and P Frame Quantisation , even if its set equal in ffvfw settings.

Maybe that VBV 7 issue will give no Problem on DVD Mode or on diff. Standalones (where in regular 224 should be the one) but when muxing with bbmpg I got many many underflows as one encoding I did, did fit amazing on one CD80 and thats why I tried to mux a SVCD VBR using that.

Cause we're doing in here kDVD encodings and thats why we use 18 NTSC and 15 PAL

I know that ! But I wanted to say that Kwag also have a VBV=7 and DON'T have any underflow ! So that is not the VBV that cause this.

Because we're testing ffvfw for making KDVDs. Not KVCDs.

Edit: was already answered

-kwag

Yes this is true Phil. The three movies I've encoded, all have a VBV size of 7.
But all have been progressive 23.976, and then ran through pulldown.exe and then DVDPatcher to patch the header to 8,000Kbps.
When muxed with Mplex, I've set "~DVD" in the muxing option, with all default values.
Multiplexing is flawless, without any underrun or overrruns.

-kwag

There really seems to be a PAL issue
I did some comparisons between 23.976 and 25.000 using ffvfw, cce and TmpgEnc.

Ok, the Pal stream is a bit different in its treatment cause I did set the Slicer to NTSC and PAL GOP specs, therefore the sliced samples where shurely different, but that should not influate the average behavior of the modes I saw as posted here:




But the very worse Q curve in compar. to CCE and Tmpg stands in no relation to the real quality in the video.
But Anyhow ... at the same endfilesize, ffvfw does look a bit better if seen as a whole! But if we would trust totally in bitrateviewer, Tmpg should look 3x worse but it doesn't if seen in the pics below.
(rised gamma/Luma via levels afterwards to compare dark parts)

@incredible
This ffvfw screenshot look amazing... What was the blockbuster setting you used? My encodes with ffvfw don't show this straight Q curve... I'll post later.

The pics are 2times scaled! And enlightned by Levels() But I think you did checked this already

This Setting ONLY affects the plain parts and NOT the details/Edges.
You can play with the "variance" values which do affect the noise level.

Also apply that one to your script at the very end before adding the blockbuster and then the borders:

(Only to use at 704,XXX encodings cause they wont be stretched horizontally that much on Tv!!)

Which would mean if seen in the Matrix (here now in TmpgENc)



That gives in my 1% Sample an advantage of compression from 13.886 to 12.898 kbyte Means 100mb less on the whole final encoding, but that also depends on the movie source and its detail quality.

On the Tv later you WON't see that less sharpenes as it even does not affect the sharpeness that much as compared to our MergeLumaBlur commands in the Ma! But its not recommendable when encoding at for example half DVD size (352x480).

Hi Inc,

Are you aware that DCTFilter is included in ffvfw



-kwag

YEP! But not DCTfilterD() !
Without that, only the 2 right collumns would be filtered, and so I did the job as a whole in AVS.

And ... I like scripting