Script for prefiltered Videos? (DivX/Xvid)
 

What are your favourite script settings when encoding already highly compressed videos (e.g. DivX/XivD movies)???
As the video should be pretty clean (or, if there was too few bitrate, blocky), would you use less or extra filters than in the optimal Script? Or maybe a "direct show source" input in avisynth to get the deblocking of ffdshow (compressing blocks ain't that fun) ???


BTW. If a topic like this already exists, which is not that old, plz tell me so this one can be deleted

Cmon guys! 54 views and no answer? :D
You can do better than that :wink:


p.s. is there a site/thread which says how much performance every filter needs??? (e.g. temporalsmoother: doubles the time; or sth like this)

now we got the 100 views... :cry:

*beg*

You'll get a cookie if you answer! (or maybe you won't... who knows :wink: )

Why don't you tried it without filters. Just open the avi in TMPGEnc/CCE, adjust resize settings and encode.

Hi Razorblade2000..

Sorry, I don't really have anything ta offer script'wise, for sources based
on divX. But, I had an idea to encode some of my dvd rips to divX and
THEN do my own "based optimal scriting" on these encodes, to find the
best technique. I also want to do an experiment, where I encode some
dvd rips of mine, to divX at the maximum quality avaible in a codec, and
later, encode to MPEG-2 and see if there is "some" benefits to this form
of archiving. Just curious stuff I've ben throwing around in the back of my head :roll: Anyways...

I'm always in the development stages when scripting. But, for me, and
mostly use vdub and frameserve into TMPG that way.

Though, lately, I've ben playing around the Kwag's MAS on and off,
and trying other filtering variations in the MA parts, and working on app
projects and things etc. It's kind of hard for me to "stay put" !!

It's hard, touching on divX sources these days, cause now articles become
locked, if you mention your sources true origin. Its not the origin that really
matters, rather that the user "not" publisize (specially on a regular bases)
the sources origin, mainly if the movie is not yet ben released. So, that's
pobably why divX discussoin or lower priorities. It's just my guess, that's
all, ..about the divX touchyness. Not you :) Anyways..

I'm not much of a divX guru, but I've encode TO divX w/ what I feel are
great results. But, i'm more too busy w/ lots of other fun things going on.
I hope someone (or two) resplies to your post, becuase it would be interesting
to see what others to or handle their divX to vcd/svcd/kvcd/ksvcd etc process via scripts.

Me, I prefer not to taint the source w/ filtering if I can swing it (not usually)
but I do hope that Kwag can come up with an arson of script-snips
for various source projects ie, divX, DVD, VHS, etc etc.

At least one person is working on VHS sources - MrTibs. He's ben
working on a .AVS filter for these.. FWIW.

And, Jorel knows how to seek out things, cause he very good at that.
He's ALL OVER the net, seeking and searching for the best things out their.
Between him and kwag (and sometimes myself included) I don't know
who gets enough sleep. Anyways...

Good luck so far,
-vhelp

wow... so much to read :lol: :lol: :lol:

I guess I'll stick with the current "optimal" Script for clean sources...

The only big problem is, that predicting CQs via CQMatic is a VERY time intensitive task... I guess it's because of the jumping arround in avi files (guess my video hasn't that many keyframes :D )
One 2400 frames predicting pass takes up to >20 minutes!!! which quite sucks... I thought about having a virtual job generated that will produce a small avi sample file which is used to predict the needed CQ so I only would have to do this once...
If you got an idea about this one: http://www.kvcd.net/forum/viewtopic....c32ff55f0a83ca

Some ideas: create a huffyyuv sample and predict manually. That's what I do. MPEG4 takes a lot of time seeking, so you do it once, encode your sample to huffyuv (which BTW is lossless) and then predict using your Huffy sample.
I tried many filters, but right now all I use is BlindPP() and sometimes Fluxsmooth... Filtering Divx also takes a long time...

[]'s
Vmesquita

update..

Ok, I managed to get divX able to frameserve into TMPG, but w/ a little
tweaking, I might be able to fix the color issue now. It's sort of blue'ish.

Anyways..
-vhelp

There come the answers :-)

And some questions:
1. You create the sample via sampler.dll?
2. What exactly does BlindPP() do???
3. When do you use fluxsmooth?


P.S.
Decoding DivX doesn't take as long as decoding MPEG2?! Does it?


EDIT:
BlindPP() is for deblocking... just did a lil research on the web... NICE!!!

Install a newer DivX codec, I think that the color swapping issue was fixed in 5.0.3.

Also, if you want to remove some of the blockiness, you can adjust the DivX decoder filter postprocessing. I have set the slider to two notches from the left so that deblocking is done on luma only. Deblocking both luma and chroma takes too much time IMO.

or better than that...
use ffdshow
WAY faster than the DivXDecoder and more options to play with! :D

Or add SwapUV() after loading the avi.

@ all.

sorry, I missed all these great posts. I've ben busy w/ my own set of problems
and now I have a huge headache that wont quict on me.

Soon as I get some time, I will.

@ Razor..
I forgot to mention, after trying out the above w/ my divX 20min sample,
TMPG was looking at over an hour 8O
So, I don't get it either. I was using a codec v5.0.2

@ Boulder..
what blocking hehe.. I thought my samples (or my encoding for that matter)
came/comes out great. I can't recall the exact settings I use in divX, but I
do know that after many test runs w/ trial and error, I manged to figure
out a decent looking process w/ the codec I use. Other wise, I'm a tadd
confused w/ what blocks you were refering to 8O

Thanks everyone again,
-vhelp

so no one has any good suggestions for filters? I notice that some of my divx and xvid files have blocky backgrounds and mosquito noise around people, and the latest MA optimal script seems to enhance these problems. It feels more and more like the old 2.0x scripts did a better job of making the blocks look like noise and smoothing out the mosquitos. Any ideas, comments, suggestions anyone?

Encode as CQ_VBR, so you can use Blockbuster (noise) :D
Blockbuster is effective with CQ_VBR, but not with CQ.

-kwag

Thank you Kwag, as always you come through! So where in the script would the blockbuster line go? Can it be motion adaptive? And would you suggest default noise parameters?

Hi J-Who,

It can be adapted to the MA script, but you should first try it with the default script and the default settings, and see if it solves the problem :)

-kwag

is it effective on all resolutions kwag? or only is for smallers resolutions....

Thanks Kwag. What I meant was where should the blockbuster line go in relation to the other filters in the optimal script? Should it be near the beginning where it is applied statically or can we incorporate it into the motion adaptive section? (and how would you suggest I do either cause I'm not too good at figuring out these things! :oops: )

BlockBuster adds noise to your clip, so it should be at the end.

At around 528x or higher, blockbuster is not needed.

-kwag

It should be used after all the temporal/spatial filters, because if not, the noise will be filtered and you don't want that :)
Put the BlockBuster filter on the last line of your script.

-kwag

Should I put it before Gripborders() or literally the last line in the script? I do notice some blockiness without blockbuster even at 528x480 resolutions, so I'm hoping blockbuster can fix it (even tho you say it's not effective at that resolution).

What exactly do you mean by this?

Yes :oops:, I should have specified that :!: Try it :) I'm just following SansGrip's recommendations, where he tested it, and came to that conclusion :cool: As above. Try it and see if it kills the blocks. Based on our previous tests, Blockbuster really is ineffective in CQ mode. Apparently, the encoder filters out a lot of the noise, and renders the filter useless. However, in CQ_VBR, it does work, but then you get worse quality on the high frequency spectrum of the encode (artifacts, etc.)

-kwag

1. Yes
2. ...
3. I use with more blocky DivX 3.11 rips.

[]'s
Vmesquita

The problem with ffdshow is that you'll have to use DirectShowSource to load the clip and thus seeking is extremely slow, making the prediction step very slow indeed. Also DirectShowSource doesn't seem to work on every system so that's another problem.

vhelp,

I was just referring to bad DivX/XviD sources in general. Low bitrates and crappy preprocessing do produce quite noticable blocks in the final video and it's sometimes very difficult to get rid of them.

Hmmmm... how about this try:

AviSource("some Southpark/Futurama/Simpsons Ep")
ConverttoYV12()
MergeChroma(blur(1.58))
MergeLuma(blur(0.05))
BlindPP()
Convolution3D(preset="AnimeLQ")
Fluxsmooth()
Warpsharp()
Undot()
Dup()
GripCrop(352, 240, overscan=0, source_anamorphic=false)
GripSize()
GripBorders()


P.S:
No blockbuster for me... Avisynth 2.52 :-(

"Razor"my friend,
:wink:

one little hint:
using resize at the end of the script can give
short final size but is extreme slow to encode!

:!:

>Real time :D
I guess I don't need resizing as these episodes already ARE 352x240 :lol:

I think I'll leave that away from no on :wink: :roll:

great,then will be faster!

:)

With last Xvid codec and Divx5.05 you do not need this ConvertToYV12() : both codec are able to provide output already in YV12. The time gain is quite big.
[/i]

Okay so I did some tests with BB and its different parameters and I've found that adding BlockBuster(method="noise", detail_min=1, detail_max=10, variance=1.0, seed=1) at the end of my script (before gripborders) does a great job in getting rid of some of the blockiness from my divx/xvid sources. This was done at 528x480 wtih CQ_VBR, but I even think it works with CQ but I'd have to go back to some of my tests to confirm this. Here's a couple questions I got for ya all:

1) Is it just me or is CQ_VBR a lot slower than CQ?

2) I'm very confused by the CQ_VBR scale. I'm encoding at CQ_VBR ~10-12. That just seems so low compared to my old CQ days! Does everything work "backwards" in the CQ_VBR world?

3) Someone else mentioned using Fluxsmooth to get rid of the divx blockiness. Could someone please shed some light on this? Is it better/faster than BB?

and last but not least

4) I've been reading stuff about how different divx codecs can slow down prediction. Like ffdshow vs divx3 vs divx5.05. If this is so which should I have? According to gspot I have about 3-4 different codecs depending on my source...

Don't bother, it's normal (except that if I remember well, I used to have a CQ_VBR near 25, and not as low as yours).

[/quote]3) Someone else mentioned using Fluxsmooth to get rid of the divx blockiness. Could someone please shed some light on this? Is it better/faster than BB?[/quote]
No, Fluxsmooth is to fix mosquitoes, not blocks.

ffdshow is a directfiltershow, not a codec and its normal to have it at the end of the rendering chain.

Morgan swither is also a directshow filter, as it DirectVobSub and DivxFreeze. I guess that you have some of these into the 3-4 you describe.

All this is normal. But the codec is always the very first element of the chain given by gspot. And that is the only one used by avisynth when you use the instruction "avisource" (you have to use directshowsource if you want to use all the filters indicated by gspot).

my friend Wilbert..

based on my divX v5.0.2 sources, your above tip WORKED !!
Colors are back to the way they are suppose to be. I'm happy :)

Thanks again pal,
-vhelp

anything new?

could someone of you, who undestands all these filters a bit give me some "general" DivX -> KVCD Script ? This would be very cool as it is much harder to get mpeg4 files to a good quality KVCD than to get DVD Files :cry:

We have done a complete thread on this subject, and found a brand new script that does great things :

http://www.kvcd.net/forum/viewtopic....455&highlight=

cool! thx!
I thougt this thread was mainly focused on the compression "blocks" of low quality divX! I guess I'll have to rad a bit in it! THX! :D

Razorblade2000,

Be sure to check the thread DialHot suggested, it does wonders to DivX sources! :D But remember that you can't get a bad quality source to produce great quality output. I would say that a 2-CD DivX source of 2 hour movie using that script can produce results close (but still inferior, and smoother) to a DVD source. But if you're dealing with a 1-CD DivX movie, the script still works great, but the quality won't be as good. Of course I am talking about quality to my eyes, might be different from yours. :wink:

<edit> the thread is mainly about the DCT blocks that appear a Lot in DivX sources (even 2 CD sources) in dark areas... The annoying "dancing blocks", as I call... I consider this the worst weekness of a DivX source. (the other weekness would be too much smoothing... But Xvid is better for this matter)</edit>

[]'s
Vmesquita

@ vmesquita :)

Is this "quaility thing" based on viewing on your PC monitor ??
Or, are you refering to how it looks viewed through a TV-OUT ??
-vhelp

vhelp,

I was refering to converting a 2-CD DivX source to KDVD using the DCT killer script. And viewing using my Philco DVP-2500 on close to a DVD backup at least for my eyes.

But you can also get good quality DivX viewing on TV-Out using a GeForce MX-200 with Svideo. But in this case it is mandatory to use post-processing and add mplayer noise on playback with FFDShow to get a good output. I used to do that all the time till I got my DVD Burner. The noise added throught FFDShow is to kill the annoying DCT Blocks.

I also tried to use Mplayer noise when encoding to KDVD but sadly it doesn't work, the noise becomes small dancing blocks in the final MPEG2 output.

When viewing on PC Monitor, DivX movies generally look great, even 1-CD rips. The DCTs become invisible, maybe because there is less contrast...

Xvid tends to smooth less the picture and retain more details.

[]'s
Vmesquita