Saving Private Ryan [Archive]

ShadowKnight

3rd June 2004, 23:46

I agree with DDogg... definately listen to what hes saying here.
I recently ran The Beatles Anthology, and it gave me a q value of 57, then after adding filters, which I decided on undot().Deen().Fluxsmooth() it came out to 45. Keep in mind that this is basically a collection of old clips of the beatles, so its got a lot of dated film. After I ran the passes with the filters, a lot of the clips looked cleaner than the original, and in fact, upon zooming it in the images stayed nice and smooth/well defined - definately not blocky, although perhaps a bit blurry if you zoom in far enough. Considering the original blocks up upon very little amounts of zoom. I'd say that it works great. So, in closing, if you have a hard to compress movie or just want to sharpen up the picture for the final encode on a borderline dvd, then filters can simplify the image so that the encode will have an easier time duplicating the picutre, and give good bitrate. I was pleasantly suprised by the quality, and that the loss that occurs before the ecoding, can actually make the clip come out looking cleaner and more accurate than it would have in a straight encode, because of the extra bitrate saved. :)
Thanks DDogg, for posting all the info you have about anything and everything, you've taught me a lot. And I'm eager to learn more. Everyone here is awesome. Thanks for being here :)

DDogg

4th June 2004, 00:11

I think filters are a little like good Irish or Scotch whiskey :) There are appropriate times to partake. It mellows you out a bit and makes everything a little less complex. Like whiskey, too much filtering just makes everything look blurry and unreal. A little is just fine for the right situation, while too much is just stupid and defeats the purpose. Each sort of makes your head hurt if overdone :)

Xuivo

4th June 2004, 00:14

Just want to ask a point? If those filters are that good, why there are not a default in DVD-RB?

Personnally i've never used them before, can you applied them everytime?

ShadowKnight

4th June 2004, 00:22

well, thats a two way street really, it does modify the image, and it might be noticable when its not needed, like in a really sharp and well encoded (easily compressable) film. it can make a good sharp movie more blurry than it needs to be. But with movies that are compressed bad in the first place, not very sharp overall, sometimes not noticable unless you zoom in(blocks!), then blurring those blocks properly with filters is the way to go. I'd check the source first before any ecode, its a good idea to look for yourself what your in for ;)

evestorm

4th June 2004, 05:51

Thanks for the Tips guys. Consider me a complete noob, so forgive some of these ridiculous questions. If I run the OPV in the latest version, how do I get the analyis with no encode? I have to uncheck the one-click mode right? Duh I suppose.

Then DDog if you could post exactly how to add these filters and change their values, that would be great.

Thanks for all the help guys.

E

Fr4nz

4th June 2004, 20:41

In CCE 2.50 the Q factor is "vbr_bias"?

If yes, i think there are different range values to give...

Noah

4th June 2004, 21:15

Originally posted by Fr4nz
In CCE 2.50 the Q factor is "vbr_bias"?
No

jdobbs

4th June 2004, 21:25

Originally posted by Xuivo
Just want to ask a point? If those filters are that good, why there are not a default in DVD-RB?

Personnally i've never used them before, can you applied them everytime? Because it most cases it is better not to use filters at all. As DDogg implied "use in moderation."

Fr4nz

4th June 2004, 21:48

Originally posted by Noah
No

So Q isn't present in 2.50, right?

evestorm

4th June 2004, 22:58

I ran the OPV analysis and got a q of 85!!!

Ouch. Any settings I should check?

E

DDogg

4th June 2004, 23:23

Ouch indeed! That was with no filters, right? Long way to go to try to reach a Q40 equivalent. Maybe we can get close to it.

To try the filters,(in 51c) go to the AVS advanced options, select "filter Editor" and type Undot().Deen() in it. Then rerun the OPV prep stage. That still will not bring Q down enough though, but do report what you get.

Well SPR is the gold benchmark for difficult compression after all. Darn, I tried to find a rental copy last night for testing, but none were available. Since I don't have SPR at hand I don't know if it has many trailers or extras? If so I would think you would be best using dvdshrink to create a movie only ISO which you can mount and source to dvd-rb.

After that, if it still is not low enough, you may have to consider cropping overscan which should buy you maybe 8-10% more bitrate reduction, but that's a little controversial. It should now be fairly easy to do cropping in the filter editor for a movie only situation. Let's deal with that if you get to that point.

jdobbs

4th June 2004, 23:32

Originally posted by DDogg
Ouch indeed! That was with no filters, right? Long way to go to try to reach a Q40 equivalent. Maybe we can get close to it.

To try the filters,(in 51c) go to the AVS advanced options, select "filter Editor" and type Undot().Deen() in it. Then rerun the OPV prep stage. That still will not bring Q down enough though, but do report what you get.

Well SPR is the gold benchmark for difficult compression after all. Darn, I tried to find a rental copy last night for testing, but none were available. Since I don't have SPR at hand I don't know if it has many trailers or extras? If so I would think you would be best using dvdshrink to create a movie only ISO which you can mount and source to dvd-rb.

After that, if it still is not low enough, you may have to consider cropping overscan which should buy you maybe 8-10% more bitrate reduction, but that's a little controversial. It should now be fairly easy to do cropping in the filter editor for a movie only situation. Let's deal with that if you get to that point. I have it and will look at it (NTSC Version). You might want to mention that the undot.dll and deen.dll files need to be downloaded and added to the plug-ins folder.

jdobbs

4th June 2004, 23:41

Originally posted by DDogg
Before you do anything, run the prepare phase in OPV mode to see the prediction. One of the great features of OPV is the diagnostic ability to predict quality before you actually do the encode. It does not matter if you actually use OPV, which for this encode I probably would not. The information the OPV prepare phase will give you is extremely useful for understanding what you will achieve.

I'm just guessing, but I suspect it will show a Q prediction in the mid 50s, or maybe even higher. Then use the new filter feature in the latest version to add undot().Deen() and rerun the OPV prepare phase prediction. That should show a drop in Q of 15 to 25%, which means there will be the equivalent drop in the needed bitrate.

It would be great if you could do that, and then report back the results of the two predictions.

If you would like, I can then suggest a few more things that may help if the predicted Q still shows high. I just tried undot().deen() on LOTR Return of the King... and I get a predicted Q of 47 with and without it... is this an anomaly that happens only on this movie?

[EDIT] This statement was incorrect. I thought I'd gotten 47 without Undot().Deen() when in fact when I went through the test again I apparently didn't record it properly. Without the filters I had gotten 53.

bobwillis

4th June 2004, 23:46

Hi,

As everyone now knows, I have done SPR (NTSC) using D2S several times. These figures are from my memory; Q without anything=75, with undot & deen=63, with undot&deen + 3% FACAR, Q=57.

Getting near 40 with SPR is nigh on impossible. However, the Q of 57 version is 'acceptable' in my opinion. Incidentally, I found Canopus Procoder v1.5 does the best job to date with this movie (if you've got plenty of time for 2 pass VBR mastering quality - 15hrs on a P4 3GHz).

BTW, it is definitely better if you use conventional VBR with this movie.

Regards,
Bob

evestorm

5th June 2004, 00:20

I am doing the R1 anniversary edition of SPR. Thanks for the help DDogg, bobwillis and the rest. I am running the undot and deen and will report the results in a bit.

Thanks again guys.

E

evestorm

5th June 2004, 01:06

Ok this time I ran the OPV analysis and got a q of 72 with Undot().Deen(). Anything else I can do?

Thanks again.

E

bobwillis

5th June 2004, 01:17

Hi E,

If you are only interested in the main movie, then run it through DVDShrink first using the re-author feature (and no compression) to get rid of the other titlesets.

You could try FluxSmooth as well; but that may overkill it. Also, you could try cropping 3% from the perimeter - I'll let someone else tell you how; since I don't know how to do it manually (I normally use FACAR with D2S).

My advice in the short term, is do the job overnight with 4 pass VBR using undot & deen, and see what you think. You may be pleasently surprised; the result will be far better than any transcoder - it doesn't block, but you may see some mosquito noise. I recommend an IQP of around 16 and a bias of between 20 and 30.

Good luck,
Bob

evestorm

5th June 2004, 01:46

Thanks Bob.

I think I just may try that. The anniversary edition has almost no extras to speak of. It's pretty much just menu and main movie.

I will give the 4 pass and filters a try. Is there a way to tell when you have reached the point where any more passes would be futile, or is it trial and error.

BTW thanks for a kick ass app jdobbs.

E

bobwillis

5th June 2004, 02:02

Hi E,

My edition (I think it was released in 2000) had a D-day documentary on it, so that explains the reported differences in Q. They could also be explained by the fact that I was using D2SRoBa (main movie only), and you are using DVD-RB.

Re: passes. My experiments suggest that nothing improves beyond 3/4 passes, and most of the time, I can't tell the difference between 2 & 4 passes. However, since this is such a difficult encode, if you've got the time & patience, I would give it the 'full 4', just so that you know it isn't likely to get any better with any more passes. If you did it with 2, you would always be thinking 'perhaps it would have been better with 4'.

If you're not happy with the result, I'm sure someone will explain (if they haven't already done so), how to remove the overscan with avisynth commands.

Let us know how you get on. I think so much depends upon what you are watching it upon. Some people on here have fantastic display equipment (going green with envy), where as I have a standard 32" widescreen panasonic. Clearly the bigger the display, the larger the defects are going to be, and the greater the possibility of seeing them.

Regards,
Bob

toliman

5th June 2004, 02:44

have you tried setting it to Half D1, instead of trying to remove the motion and artificial grain using flux/deen filters ?

SPR is a tough film to re-encode, as are most WW2 films because of the "gritty" film look, along with the hand-held camera motion.

i imagine if you had the time, there is a good filter chain in HybridFuPP (http://forum.doom9.org/showthread.php?s=&threadid=75669), that will reduce the Q and keep the visual quality you want. it's based on motion masks, edge and scene detection, with the intention of filtering fast-moving objects that you don't notice, more than still or slightly moving objects that will be softened when you run undot().deen() . it's official task is a hi-quality resizer, which for DVD rebuilding at 2-3Mbit, is probably overkill, but below 2Mbit, it might suit.

i'd check what Q you get with 1/2 D1 first,
then, if you really have the time and want it to look good, maybe try HybridFuPP as a resizer.

toliman

5th June 2004, 02:56

Originally posted by bobwillis
you could try cropping 3% from the perimeter - I'll let someone else tell you how; since I don't know how to do it manually (I normally use FACAR with D2S)

are you referring to overscan borders ?
i.e. the black edges on dvd content.

if so, it will require a few careful crops and resizes that take a little bit of time to manually process. i'm not a fan of overscan in dvd's, the best method i would recommend is not FACAR, but Sansgrip's GripResize, which handles ratio's and resize options without the need for manual intervention or configuration. however, it's best avoided if you can help it, since it adds complexity without discernible results in quality.

DDogg

5th June 2004, 05:33

Originally posted by toliman
however, it's best avoided if you can help it, since it adds complexity without discernible results in quality. I don't think the part of your statement that I put in bold is correct because the effects upon bitrate by cropping can be quantified as a reduction of bitrate. The following example shows a full 10% bitrate reduction to achieve Q28 when the bitrates of the samples were derived.

Example: Timeline 4:3, 166,082 Frames, Sample 1%, Q28 OPV
Method: Sample run using script below with cropping rem'ed for uncropped sample. Kbps Bitrate derived from sample filesize using this (http://forum.doom9.org/attachment.php?s=&postid=475110) spreadsheet.

Filtered_Uncropped - Required bitrate to contain Q28 = 3457 Kbps
Filtered_Cropped - Required bitrate to contain Q28 = 3112
Yields an addtional 10% reduction in required bitrate.

[Q28 is not significant here. It is just the reference constant I use when doing testing]

Some other related results -

UNFiltered_Uncropped - Required bitrate to contain Q28 = 3925 Kbps
UNFiltered_Cropped - Required bitrate to contain Q28 = 3436 Kbps
Difference from UnFiltered_UnCropped of 3925 Kbps to Filtered_Cropped of 3112 Kbps is 20.7 % if I did my math right.

This source did not respond to filtering as much as I have normally seen. That is why you have to do the calculations. To risk sounding like a broken record, each source has a unique bitrate requirement and they all respond slightly differently to filtering.

Sample Script used [I seldom use GripFit so I may have done this incorrectly]. Also note the source was 4:3 fullscreen -

MPEG2Source("D:\timeline\timeline.D2V")
Undot().Deen()
GripCrop(704, 480,source_anamorphic=false,dest_anamorphic=false, overscan=1)
gripsize()
gripborders()
ConvertToYUY2()
SelectRangeEvery(1200,12)

/Add - forgot to mention all the tests above used CCE standard matrix. When I substituted the Bach matrix, the Kbps dropped to 2831. So, for this encode (Timeline), we started at 3925 Kbps to contain Q28. With filtering, very light cropping, and using the Bach matrix we have gotten it down to 2831 for a total of approx 28 % reduction in bitrate requirement.

If I can get a copy of SPR maybe I can do the same calcs and report back.

luphy

5th June 2004, 09:12

FYI,

LOTR Return of the King, movie only without menus, with English subtitle and 6-channel sound only (and no manual bitrate adjustments):

No Filters: Q selected = 46
deen().undot(): Q selected = 37
fluxsmooth(): Q selected = 41

DDogg, in another post, you mentioned you got this movie down to the 20's? How do you go about using the trim option (and just exactly what does this do?). Thanks.

Sorry for being slightly OT, but since this seems to have shifted to talk of filters....

Addendum: sorry noticed you placed your trim commands in your last post....does this basically remove the black bars above/below the main movie?

DDogg

5th June 2004, 19:43

luphy, like I said, I am not sure enough about using GripFit to make a proper recommendation, especially since I used FACAR for doing that encode in D2D. I can make a pure guess though on what might be equivalent to that script. You can try it and see if it works for you. Just remember this is a W.A.G. on my part and don't beat me up if it does not resize correctly.

GripCrop(width=704,height=480, source_anamorphic=true,dest_anamorphic=true,overscan=2) #maybe 3 ?
Undot().Deen()
lanczosresize(GripFit_resize_width, GripFit_resize_height)
# or rem line above and unrem GripSize() below, which uses simple bilinear resizing
#GripSize()# will compress better but not look as sharp as above
GripBorders()
Also, remember I used the Bach Matrix which made a good contribution to reducing the bitrate. I don't know how you would use a different matrix in dvd-rb OPV mode now. I don't think you can. That's why I keep asking for CCE SP template support like D2D uses. That would make it very easy to use different matrices. I think Robot1's new tool allows you to use custom matrices in multipass. Check that thread and ask him.

Hopefully somebody who remembers the older manually cropping and resizing methods can offer a better suggestion, or can correct the one above if incorrect (probably is). JDobbs probably remembers all that old manual stuff :). You can find the GripFit yv12 dll here (http://forum.doom9.org/attachment.php?s=&postid=490683).

onesoul

5th June 2004, 20:16

@DDogg, luphy

I used LOTR Two Towers (clean source) to do some filter comparisons trying to find the ones which would do less harm to original source and came up with a filter chain, check the comments and suggestions thread (http://forum.doom9.org/showthread.php?s=&postid=506356#post506356).
Fluxsmooth imo is great for cg animation and better than deen with natural pictures. Deen seems to blur too much also imo. VagueDenoiser seems to be all suitable filter. Dctfilter smooths tiny (8x8) blocks only where it needs at least with the default settings. I am happy using the results. :) Try it and post some comments on it.

jdobbs

5th June 2004, 20:30

Originally posted by luphy
FYI,

LOTR Return of the King, movie only without menus, with English subtitle and 6-channel sound only (and no manual bitrate adjustments):

No Filters: Q selected = 46
deen().undot(): Q selected = 37
fluxsmooth(): Q selected = 41

DDogg, in another post, you mentioned you got this movie down to the 20's? How do you go about using the trim option (and just exactly what does this do?). Thanks.

Sorry for being slightly OT, but since this seems to have shifted to talk of filters....

Addendum: sorry noticed you placed your trim commands in your last post....does this basically remove the black bars above/below the main movie? At the risk of starting another flame war... I just don't understand these comparisons -- or more accurately I do understand them and have a hard time with them.

Comparing Q values after a filter is not a good representation of the quality of the resulting video. If you blur an image beyond recognition and then sample to see what Q you'd get it would be very low -- but the quality would be terrible. Try it some time.

What I'm saying is that Q means nothing if you measure it against an input that has been filtered.

I'm not saying that filters are bad -- I'm saying that comparing Q after filtering is meaningless.

DDogg

5th June 2004, 21:19

If you blur an image beyond recognition and then sample to see what Q you'd get it would be very low -- but the quality would be terrible. Yep, it sure would and I can't imagine your statement causing any flames. I do think the rough methods I use depend upon the few selected filters which are used to provide a 'constant' value to the equation. What I mean is: I know none of them will overly effect the 'viewability' of the video; none will do what you suggested above. So, while a Q28 filtered may not be the same as a Q28 unfiltered, I still know it will be acceptable to my eyes.

What I do know is:

A filtered encode using my personal filter constants at Q28 is more enjoyable to watch than an unfiltered encode at Q40-50.

Using the information gathered from sampling and deriving the resulting bitrates provides me with a practical method to predict the quality, well maybe the 'viewability' would be a better way of putting it. Whether is is theorectically correct I don't know. From a practical standpoint it seems to work ok for me and has never steered me wrong. I'm just looking for a relatively simple method to point me to the actions needed to achieve a highly watchable movie.

To really have an enjoyable discussion on the topic would require actually knowing what the CCE Q-Value used in OPV does/what it measures. To my knowledge nobody knows this and without that knowledge, theoretical discussion is near a moot point in my mind.

jdobbs

5th June 2004, 21:41

This comes to one of those "whatever steers your boat" discussions. I use filters extensively on captured television or DV input. I don't think it's even worth wasting your time encoding an off-the-air source without temporal filtering. In those environments they are invaluable.

I know you understand the difference, DDogg, I just wanted to make sure everyone else does as well. Sometimes these numbers can be incorrectly interpreted as incontrovertible mathmatics. I've seen that happen with PSNR in the past. ;)

onesoul

6th June 2004, 00:06

I would like to emphasize that I did my filter tests using avscompare 2.5 using a lot of zoom at different kinds of scenes, took me more than a couple of hours trying diverse settings and arrangements of filtes. Why am I saying that, I really don't know.

DDogg

6th June 2004, 01:34

This comes to one of those "whatever steers your boat" discussions. No, I'm still not sure you understand my meaning. Q measurements with filters ARE incontrovertible mathematics. A Q28 with a known filter is just as precise a value as a Q28 without a filter. It is a replicatable and portable precise measurement that can be used in valid calculations and communicated to others. Doesn't really matter if the two Q28s are, or are not not the same. The fact is, one is as valid a measurements as the other is. Both are highly useful.

As to IF they are the same, again, I don't think anybody can express strong opinions, and should not attempt to, simply because nobody understands what Q-Value is actually measuring. At least I certainly don't know. Bach did not know. Do you know??

jdobbs

6th June 2004, 03:23

Here we go again. I knew I should have just not commented and let this thread go on -- no matter how wrong it is.

I understand your meaning -- I don't think you understand mine. I absolutely disagree for the reasons I've mentioned above. Q is the quantization factor. It says so on the CCE screen and again in the CCE manual. I think we all know what quantization is... don't we? If you get rid of sharp edges in your video you can lower the visual affects of quantization. So if you are filtering out sharp edges you can lower Q -- but not necessarily improve picture.

Here is the referenced statement:
No Filters: Q selected = 46
deen().undot(): Q selected = 37
fluxsmooth(): Q selected = 41
Where is the "portable precise measurement" in that...

So I guess there was an opportunity for "flame" in this after all. I'm done with this discussion -- and everyone who wants to believe that you can use Q as a mathmatical comparison of filters can feel free to do so... incorrectly.

onesoul

6th June 2004, 03:33

Ignorance is bliss :)

Anyway I think you misunderstood what jdobbs was refering to. I think he never talked about a Q filtered or unfiltered being more or less precise. I think it was the achieved Q after applying a filter would have different meaning since those filters would alter the appearence and visual impact and although some filter(s) could make no difference to your viewability it would rather depend on subject and/or viewer.

And trying to find the minimal impact on image quality by filters applied while removing noise was my suggestion (at least what I tried to do with my tests which of course are subjective and debatable).

edit: damn, jdobbs kicked off the ball first

DDogg

6th June 2004, 06:21

Man, a person needs asbetos underware around here. If you disagree, then refute with logic instead of a blowtorch for goodness sake and please quote your source material. This is supposed to be fun and educational I thought? Originally posted by Jdobbs- Q is the quantization factor. It says so on the CCE screen and again in the CCE manual. Oh? Are you suggesting that OPV is a constant quanitization model like TMPG CQ? That has not been my understanding, but then I'm no expert. Maybe that is why we are speaking past each other so much lately. Nobody, to my knowledge can yet define what Q-Value measures. You seem to be saying that you can. Ok, so tell us all and educate us. PLEASE!

Here are the quotes from the manual that popped out at me on the subject. Maybe I missed the one you are referring to. They suggest to me that Q is not a straight quantization constant and that Q is NOT just quantization factor. MPEG-2 (ES, One-pass VBR)Outputs MPEG-2 video elementary stream in one pass variable bitrate (One-pass VBR) mode. The bitrate of each GOP varies but quantization scale is almost the same - 2.Now footnote 2 says, 2 The quantization scale may be changed in order to keep upper and lower bounds of bitrate. So, it seems not what you said. At least I believe that contradicts your statement. The manual continues - Q.factor is a parameter unique to Cinema Craft Encoder. This parameter influences quantization scale and can be specified only in one pass VBR mode. Now Bach spent a lot of time trying to figure OPV Q value and frankly I think he is probably a lot smarter than either of us. Certainly much smarter than I. He mentioned, Attention that the Q.factor is an exclusive concept of CCE, directly related with the quantisation, but it does not mean QM nor S, and it is not very clear the way that it is calculated. Based in the results of my tests, I believe that Q.factor is in some way proportional to the average value of the product QM(i, j)*S. Anyway, the Q.factor is the direct measure of the quality to be gotten so that, if two different films are recompressed using the same settings and the same Q.factor, can be guaranteed that they have the same quality.
If you dispute that fine. Just refute it with logic. Maybe I can get him to come discuss it with you. I just take his word for it on most of the benchmark stuff I try to do.

btw, are you saying that two encodes of the same source using the same exact filters yielding the same Q would not be portable? If, so I would respectfully disagree. This is what I meant by "portable precise measurement". Maybe "portable precise benchmark for comparison of results" might have been better wording? If that is wrong, please show me how it is. You see, I have no problem being proven wrong. That is how you learn something. If you get rid of sharp edges in your video you can lower the visual affects of quantization. So if you are filtering out sharp edges you can lower Q -- but not necessarily improve picture. Absolutely agree with you as from a theoretical standpoint which seems to be your focus. Mine is for the practical application. Please go back up and note my comment in bold about depending on a known filter as a constant as part of the benchmark. That's an important bit.
--------------------------------------

@Onesoul, yes, I understood exactly what he was saying and I think I agreed with him, didn't I? Maybe I did not do so clearly enough and you felt the need to interpret and interject? My point was A Q value of X with a known filter of X acting upon a known source of X is replicatable and portable. It is a valid and useful measurement unique to itself, JUST as is an unfiltered Q value. Would you disagree with that? If so, please educate away my blissful ignorance, which I think you were suggesting I enjoy? :eek:

jdobbs

6th June 2004, 06:38

Well I started to draft a response, but instead, I'm done. The quotes you've shown here only substantiate what I said. It is apparent to me from your response that aren't interested in logic, only in trying to argue. From here forward please do that with someone else.

DDogg

6th June 2004, 07:02

Well that is the point, Jerry. You seem to have some problems with drafting proper responses that speak directly to the discussion points. Rather, it seems like your replies to me and many others go off on a some tangent. I am not the best at that, either, but I do try to treat you respectfully and reply to your discussion points directly. I don't really understand why you seem so mean spirited in your communication directed at me. Generally I get along with most folks fairly well. Anyway, I agree that for some reason we can't seem to connect and have any harmony in our discussions. It makes sense then not to have any further as you suggested. These have sure not been very fun, which is why I do this stuff. Good luck again on the project, it is coming along well. I like the new features a lot.

luphy

6th June 2004, 08:05

I think both DDogg and jdobbs have valid points.

From my totally uninformed position, I can see that just using the predicted Q values after using filters as a way to measure quality does not guarantee that the movie will look as good as the same movie (unfiltered) at the SAME Q value (jdobbs point). Basically it's not an undisputable reflection of true 'quality'. Makes perfect sense since you can't predict what the filters might do. You can't even say that using filters and reducing the Q value even by 1 would even give you the same quality as an unfiltered encode because using the wrong filters could do more harm than good (everyone's point of view). In fact, CCE may say a Q is lower by 5 by using X filter, but to a human eye, the "quality" may be much worse. Again, no one knows how CCE determines this Q (as far as I know, which is nothing), but it obviously will never, ever replace a human eye (that much I do know heh).

But since CCE has created this nebulous Q value to measure a movie's 'quality', and most people seem to have proven that GENERALLY, lower Q is always better than higher Q's....that we can still use the predicted Q values to assist us in determining (to some extent obviously, and never with absolute certainity) how much 'quality' we can gain from using certain filters. I think DDogg is supporting this point of view, but is also agreeing that this Q value as a measurement of a movie's "true" and "undisputable" quality is wrong. jdobbs asserts that you can't just use a Q value to quantitatively prove that using one filter over another one will provide a better encode. And he's absolutely correct and DDogg seems to agree with that as well. DDogg asserts that you can use the Q values to some extent to assist you ONLY IF YOU KNOW HOW TO USE THE FILTERS CORRECTLY and JUDICIOUSLY.

So have I read all your statments correctly?

So it seems both DDogg and jdobbs are really both agreeing, but their arguments are on different PLANES (happens all the time during "disagreements" if you listen carefully :) )

But DDogg and jdobbs do seem to disagree on one point: using Q to assist in determining how effective a filter will improve a movie. But if you read carefully, they are still agreeing. jdobbs disagrees because it is not a true and absolute representation of quality, and does not want people to just arbitrarily say one filter is better than the other, and using only this predicted Q as the basis for their arguments. I think DDogg would agree with that. But DDogg, being experienced, and far different than jdobb's intended audience, knows how to use filters judiciously, so is able to use that Q as a representation of how well a filter works.

Right? No? Oh well.... :)

DDogg

6th June 2004, 09:34

luphy :goodpost: Just to make sure it is clear, I'll quote my own post here and further clarify it.
Q measurements with filters ARE incontrovertible mathematics. A Q28 with a known filter is just as precise a value as a Q28 without a filter. It is a replicatable and portable precise measurement that can be used in valid calculations and communicated to others. Doesn't really matter if the two Q28s are, or are not not the same. The fact is, one is as valid a measurements as the other is. Both are highly useful.
I am not suggesting they are the same. Rather, I am saying the filter set is a constant and Q values delivered while using that constant filter set are replicatable and are a valid metric.

A clear example, Jdobbs reported his results from lotr-rotk to the group. He got 53 without and 47 with undot().deen(). I also got 53/47 using Undot().Deen() and reported to the group somewhere in one of these unpleasant threads, AND ANYBODY ELSE DOING THE SAME WILL GET THE SAME VALUES assuming common versions of software and filters, settings, etc.. That is an example of why I said, "It is a replicatable and portable precise measurement that can be used in valid calculations and communicated to others."

Note also, I mentioned, "I do think the rough methods I use depend upon the few selected filters which are used to provide a 'constant' value to the equation."

Those statements seem fairly clear when read, but of course it must be read - and understood.

What is clear is that Q can be used as a relatively precise constant on unfiltered video. What is also clear is Q value, when coupled with a filter which is also a constant, will return an equally precise metric. That provides useful and practical benchmark data for the users of this forum.

Maybe we should shorthand that to Quf and Qf? :) I can tell you that any source filtered with Undot().Deen() at a Q of 28 will be acceptable to me. I can also tell you that any source encoded with CCE multipass using a Kbps equivalent to the derived bitrate of a Q28 sample using Undot().Deen() will also be acceptable to me. I suspect rather strongly it would be acceptable to most folks, but that is their business.

Frankly, I'm just tired of all this. This community has changed.

luphy

6th June 2004, 10:10

True. Q unfiltered is a constant assuming the source is the same. And assuming certain filters work by mathematical constants, then the calculated Q-filtered should also be a constant. I don't think anyone argues that point. But obviously, no one can prove that a movie will look better using X filter as opposed to Y filter because Q-filter (X) is lower than Q-filter (Y). I don't think anyone's tried to argue that point heh.

But in the hands/eyes of someone experienced, that Q-filtered can be a useful indicator. But again, everything has to be checked with the human eye with regards to quality...which in itself is quite subjective and never a constant! :) (Tangent: see last paragraph **)

But you have to admit that noobs like me who don't understand the finer points of filtering might just jump to conclusions and use that Q-filtered value as the absolute and definite proof that this filter will give a better result. I would have if I had not read beforehand the posts made by the forum members here! I think that jdobbs is mainly against trying to quantify quality, filtered or unfiltered, because of its uncertainity, and because people will get so obsessed with the numbers themselves, that they forget to check the quality with their own eyes.

Btw, I posted those Q-values previously not to prove or disprove that one filter works better than the other. It was just FYI for those who know anything about those filters (my company excepted...have never used any filters, but trying to learn first).

**I think the larger argument in all of this is whether any program can reasonably represent 'quality' with one number since 'quality' is very much subjective. Yes, there are certain absolutes (huge macroblocks, grain) and extremes, but 'quality' to one person may be 'cr@p' to another. For me, I'm glad I'm poor and blind - ignorance is bliss when you don't have a huge HD set and great eyes to discern defects in even original DVDs!! :p

In the end, I will say as a noob that I value the opinions of those here who say certain filters seem to work well on this movie, on their set. It then motivates me to learn more about that certain filter, and maybe to try it out for myself - with the final opinion of whether the filter really works or not up to me.

No absolutes in life. Just lots of greys.

Oh, another rambling tangent from someone bored and sleep-deprived: I heard from an elderly person once that the biggest lesson they learned in life was to learn how to pick their battles.

(Man, I'm long-winded.....)

evestorm

6th June 2004, 13:47

Ok guys...

When I try to use undot().deen(), to do a full encode of SPR, I am getting all kinds of checksum errors, When I remove undot().deen(), from the avs filters, I dont get these errors. Any ideas? Both of the dll's are in the filters folder for AVS 2.5. I just type "undot().deen()" with no spaces in the filters part of DVD-RB right?

E

Fishman0919

6th June 2004, 14:03

Did you Load the Filters, you need to load the filters first.
In DVD-ReBuilder it should look something like this.

LoadPlugin("C:\Where you put the filters\undot.dll")
LoadPlugin("C:\Where you put the filters\deen.dll")
Undot().Deen()

Hope this helps

wmansir

6th June 2004, 14:48

Originally posted by evestorm
Ok guys...

When I try to use undot().deen(), to do a full encode of SPR, I am getting all kinds of checksum errors, When I remove undot().deen(), from the avs filters, I dont get these errors. Any ideas? Both of the dll's are in the filters folder for AVS 2.5. I just type "undot().deen()" with no spaces in the filters part of DVD-RB right?

E

Did you run an encode first without the filters? If you did and the .vaf files are still there, that could cause a problem. If that's the case, just delete the .vaf files in the D2VAVS dir.

Also, like Fishman said you should double check to make sure the filters are loading correctly. Open the .avs files in a media player, if you see video they should be fine. Sometimes a setup can get hosed and plugins don't autoload.

evestorm

6th June 2004, 16:11

Hey guys...

Thanks for all the help.

@Fish Yep you are right I was a dumb ass and didnt load them up...DOH!!! Thanks bro.

wmansir thanks for the info...would have probably never deleted the vaf file created from the initial analyze.

Predicted Q is showing up as 73. With AVS does a resize filter help? In other words, I remember that with TMPGenc, if you resized and cropped the image cuting the space that the video used for the black bars, by cropping to create the black bars, you could save some space. In this case, if there were an AVS filter to do that, would it throw some more available bitrate my way? If so..anyone have any good resize filter reccomendations?

Thanks again for all the help guys.

E

wmansir

6th June 2004, 16:44

Cutting out the black bars only works for MPEG4. MPEG2 needs a standard frame size. If your source was particularly bad you could gain some compression by cutting out the 'noisy' bars and recreating 'clean' ones, but that's not very likely on a disc like SPR.

It's also possible to gain some compression by re-aligning the letterbox on the macroblock boundaries. The theory is that it is 'difficult' for the encoder to create a sharp line thru a macroblock (the small blocks the encoder divides the image up into), but it is easy if the line is perfectly aligned with a macroblock boarder. So by aligning your letterbox lines (where the picture ends and the boarder begins) you make it easier to create that line. In practice this means you crop the picture and make the boarders a multiple of 16 pixels. I don't know how much, or even if, this has an effect. It would be interesting to test out.

Trahald

6th June 2004, 20:09

Originally posted by wmansir
Cutting out the black bars only works for MPEG4. MPEG2 needs a standard frame size. If your source was particularly bad you could gain some compression by cutting out the 'noisy' bars and recreating 'clean' ones, but that's not very likely on a disc like SPR.

It's also possible to gain some compression by re-aligning the letterbox on the macroblock boundaries. The theory is that it is 'difficult' for the encoder to create a sharp line thru a macroblock (the small blocks the encoder divides the image up into), but it is easy if the line is perfectly aligned with a macroblock boarder. So by aligning your letterbox lines (where the picture ends and the boarder begins) you make it easier to create that line. In practice this means you crop the picture and make the boarders a multiple of 16 pixels. I don't know how much, or even if, this has an effect. It would be interesting to test out.

That is a feature of FACAR for svcd. and over a film length it helps quite a bit. it crops out the border (plus overscan) and sticks to blocks of 16 (for svcd) and then pads back out to spec with solid black(or near black.)

DDogg

7th June 2004, 04:27

evestorm, if you are not exhausted yet, could you do me a favor and paste the lines below into the filter editor, run the OPV prep stage, and report back the Q. This is a drastic and controversial solution, but it may work for you given this very difficult encode.

gripcrop (width=704,height=480,source_anamorphic=true,dest_anamorphic=true,overscan=3)# or 2
Undot().Deen()
gripsize()
gripborders()

Download this (http://forum.doom9.org/attachment.php?s=&postid=490683) and put in your avisynth plugin folder.

evestorm

7th June 2004, 14:00

Originally posted by Fishman0919
Did you Load the Filters, you need to load the filters first.
In DVD-ReBuilder it should look something like this.

LoadPlugin("C:\Where you put the filters\undot.dll")
LoadPlugin("C:\Where you put the filters\deen.dll")
Undot().Deen()

Hope this helps

Fish...

I copied and pasted those lines exactly. just changing the path wehre my dll's are stored into the AVS plugins directory. When I run the encode then I get checksum errors like crazy when CCE starts the encode. Any Ideas? When I remove them from the filters, I don't get the errors, so they definently are the problem, but how do I make them work right? Do I just type the LoadPlugin Limes in the filter editor, or do they belong in the ini rebuilder.ine file?

@DDogg... Sure bro I will try it as soon as my regular 4 pass finishes and report the OP results. Do I just paste the lines directly into the editor or do I have to put the loadplugin things in the ini? Always willing to try. Thanks again for all the help guys.

Oh and wmansir, I made sure that I deleted the DVS folder before I started, so the old vaf files werent getting in the way. When I remove the filter, the program works fine. I am sure that I am just missing something. Thanks again guys.

E

Fishman0919

7th June 2004, 19:25

@evestorm
Make sure you have the right ver. filters for the ver. of avisynth you have, you should have ver. 2.5 of the filters and ver. 2.5 or above of avisynth. http://www.avisynth.org/warpenterprises/

again, I hope this helps

edit: maybe try to reinstall avisynth, I had tons of problems at first but after reinstalling avisynth them seamed to go away

evestorm

7th June 2004, 20:36

Cool...

So I just put the dll's in the plugins directory and then go to the AVS filters option and paste :

LoadPlugin("C:\Where you put the filters\undot.dll")
LoadPlugin("C:\Where you put the filters\deen.dll")
Undot().Deen()

Is that right? For some reason I was under the impression that the LoadPlugin part had to be in the ini.

In DDogg's example above he doesnt have anything about the Load Plugin thing and I didnt know if I needed to type whay you posted verbatim after placing the plugins in the right place.

DDogg if you check back in, let me know if all I need to do is place the dll's in the plugin directory for avisynth and then paste your example directly, or if I need to edit an ini file or any other steps.
Thanks for the reply.

E

k-c-ksum

7th June 2004, 23:03

Hopefully somebody who remembers the older manually cropping and resizing methods can offer a better suggestion, or can correct the one above if incorrect (probably is). JDobbs probably remembers all that old manual stuff :). You can find the GripFit yv12 dll here (http://forum.doom9.org/attachment.php?s=&postid=490683). [/B]

for 16:9 pal stuff:
Crop(2,16,688,572)
AddBorders(16,2,16,2)

4:3
Crop(16,16,688,544)
AddBorders(16,16,16,16)

evestorm

7th June 2004, 23:26

Originally posted by DDogg
evestorm, if you are not exhausted yet, could you do me a favor and paste the lines below into the filter editor, run the OPV prep stage, and report back the Q. This is a drastic and controversial solution, but it may work for you given this very difficult encode.

gripcrop (width=704,height=480,source_anamorphic=true,dest_anamorphic=true,overscan=3)# or 2
Undot().Deen()
gripsize()
gripborders()

Download this (http://forum.doom9.org/attachment.php?s=&postid=490683) and put in your avisynth plugin folder.

Ickkk!!!

Q=217!!!

Anything else you think I should try while Im at work? :cool:

E

DDogg

8th June 2004, 00:08

I think you will see some very weird stuff if you play one of the avs files. Verify those lines were added to the scripts and that you got them correct. That result is impossible if the avs shows proper video in WMP when you play it. Play it and let us know what you see. Oops :) Are you NTSC or pal? I should have asked before.

Fishman0919

8th June 2004, 00:43

Correct. Paste just as I typed it.

LoadPlugin("C:\Where you put the filters\undot.dll")
LoadPlugin("C:\Where you put the filters\deen.dll")
Undot().Deen()

...but change the Dir. to where you put the filters.

hope it helps...let me now how it goes

evestorm

8th June 2004, 00:53

Originally posted by DDogg
I think you will see some very weird stuff if you play one of the avs files. Verify those lines were added to the scripts and that you got them correct. That result is impossible if the avs shows proper video in WMP when you play it. Play it and let us know what you see. Oops :) Are you NTSC or pal? I should have asked before.

I am NTSC. I copied and pasted the lines exactly as follows.

gripcro(width=704,height=480,source_anamorphic=true,dest_anamorphic=true,overscan=3)# or 2
Undot().Deen()
gripsize()
gripborders()

I am going to retry now.

Here is what the ini file looks like btw.

[Paths]
CCE250=D:\SPRSTUFF\EclCCE.exe
MPEG2DEC=D:\SPRSTUFF\MPEG2Dec3dg.dll
Source=D:\SPRSTUFF\
Working=D:\DVDR\
[Options]
LoadPlugin=1
OneClick=0
NoWarn=1
CCE=0
AVSFilter01=LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\undot.dll")
AVSFilter02=LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\deen.dll")
AVSFilter03=gripcrop (width=704,height=480,source_anamorphic=true,dest_anamorphic=true,overscan=3)# or 2
AVSFilter04=Undot().Deen()
AVSFilter05=gripsize()
AVSFilter06=gripborders()
AVSFilter07=
AVSFilter08=
[Setup]
sLanguage11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
[CCEOptions]
VBR_bias=25
Quality_prec=16
eclPasses=4
OPV=1

Will report back in a few

Update: I get an error unrecognized exception in Line 6 when I try to play the avs files in wmp. Nevermind, they are playing now.

E

Update: I played the AVS files in wmp and they played properly and I still got the 217 Q.

E

DDogg

8th June 2004, 01:51

Forget the INI! :) Paste in one of the AVS files from the main movie that will play ok for you in WMP.

Btw, if you have to use a loadplugin line then your avisynth installation has been corrupted by a poorly mannered program. You should be able to put any standard DLL in your plugins directory and use it without needing a loadplugin line.

Also, it is a good idea to use a mounted ISO image as your source now that dvd-rb supports it properly. That removes a lot of potential user error.

Also, search your HD for any instances of avisynth.dll. Delete them all and then reinstall this version (http://prdownloads.sourceforge.net/avisynth2/AviSynth_200304.exe?download) of avisynth just to make sure. You are having too many problems that nobody else has, so I suspect your installation of avisynth, or dvd-rb and the correct version of mpeg2dec3dg.dll

evestorm

8th June 2004, 02:01

AVS file looks like this when pasted:

#------------------
# AVS File Created by DVD Rebuilder
# VOBID:01, CELLID:04
#------------------
gripcrop (width=704,height=480,source_anamorphic=true,dest_anamorphic=true,overscan=3)# or 2
Undot().Deen()
gripsize()
gripborders()
ConvertToYUY2()
AudioDub(BlankClip())

I recieve an error : "Script error Invalid arguments to function "gripcrop" line 5.

Also I just added the LoadPlugin on a suggestion from another helper in this thread. the AVS install isnt corrupt I dont believe as it was one of the first things I installed when I reformatted and installed XP a few weeks ago. Thanks again for all the help guys.

E

DDogg

8th June 2004, 02:17

:confused:

The script should look something like this:

#------------------
# AVS File Created by DVD Rebuilder
# VOBID:04, CELLID:01
#------------------
LoadPlugin("C:\Program Files\DVD-RB\MPEG2Dec3dg.dll")
mpeg2source("D:\WUTEMP\D2VAVS\V03.D2V") # YOU HAVE TO HAVE THIS
trim(16421,20880)
gripcrop (width=704,height=480,source_anamorphic=true,dest_anamorphic=true,overscan=2)
Undot().Deen()
gripsize()
gripborders()
ConvertToYUY2()
AudioDub(BlankClip())

The absolutely first thing you should do is download the correct mpeg2dec3DG and put it in your dvd-rb directory. Then go to Options>Setup and "Path Mpeg2dec3dg.dll" and check "add to avs file". Browse to the dvd-rb directory where you copied the correct mpeg2dec2dg.dll from this package (http://www.avisynth.org/warpenterprises/files/decodefix110.zip). Yes, so long as the correct version of mpeg2dec3dg is in your plugin directory you technically don't have to do this, but with so many new versions of mpeg2dec3dg floating around in the last few weeks it is important to isolate the specific version to the dvd-rb directory to make sure it is always used.

evestorm

8th June 2004, 02:21

Originally posted by DDogg
:confused:

The script should look something like this:

#------------------
# AVS File Created by DVD Rebuilder
# VOBID:04, CELLID:01
#------------------
LoadPlugin("C:\Program Files\DVD-RB\MPEG2Dec3dg.dll")
mpeg2source("D:\WUTEMP\D2VAVS\V03.D2V") # YOU HAVE TO HAVE THIS
trim(16421,20880)
gripcrop (width=704,height=480,source_anamorphic=true,dest_anamorphic=true,overscan=2)
Undot().Deen()
gripsize()
gripborders()
ConvertToYUY2()
AudioDub(BlankClip())

The absolutely first thing you should do is download the correct mpeg2dec3DG and put it in your dvd-rb directory. Then go to Options>Setup and "Path Mpeg2dec3dg.dll" and check "add to avs file". Browse to the dvd-rb directory where you copied the correct mpeg2dec2dg.dll from this package (http://www.avisynth.org/warpenterprises/files/decodefix110.zip). Yes, so long as the correct version of mpeg2dec3dg is in your plugin directory you technically don't have to do this, but with so many new versions of mpeg2dec3dg floating around in the last few weeks it is important to isolate the specific version to the dvd-rb directory to make sure it is always used.

About to leave for home. Will double check this and report the results DDogg. Thanks again.

E

DDogg

8th June 2004, 02:41

This script will ONLY work if all you see in the left window of dvd-rb says 16:9. If anything says 4:3 you can not use the gripfit lines I mentioned as the filter editor does not allow them to be selectively applied.

/Add: Very sorry I even brought cropping up. It is just going to cause people a lot of grief and confusion with the mixed aspect ratios. Live with what Undot().Deen() gives you. That's about the best you are going to get.

The only way you could use this is if you first used DVDShrink to remove everything but the main 16:9 movie.

toliman

8th June 2004, 05:43

Originally posted by DDogg
[B]I don't think the part of your statement that I put in bold is correct because the effects upon bitrate by cropping can be quantified as a reduction of bitrate.

this conversation moved a long way away from SPR.

i agree with a lot of the commentary and the mild flaming earlier, IMO, Q is a subjective metric for each movie. adding filters and/to compare Q, is extremely unmotivating, since it's mostly a bitrate comparison, not a visual quality indicator -- you are observing a mechanism rather than the result. and once it becomes subjective instead of empirical and rational, well ... the conversation derails quickly. (most times it will derail for any number of reasons, but attacking credibility seems to be a favourite.)

i do know that SPR is a hard movie to re-encode well in any codec. Hence it's application in the MPEG-4 codec stress test/shootout, as a 163min movie that encodes as if it were a ~240min movie.

i might try again myself with my copy of SPR, the new DVD-RB and some avisynth filter chains, but i would first try to see what the Q pass is for 1/2 D1, even though it is 25% of the original resolution.

also, is there some relative intelligence in avisynth to detect the ratio from the d2v/source frames and crop/resize accordingly, or is this taken from parsing the ifo/vob files ?

if the latter, i guess that it depends on dvd-rb to ... segment unique avisynth scripts appropriately for each section and kind of content e.g. interlaced, anamorphic, progressive, film, hybrid, etc. something that would only be useful for extremely methodical dvd reconstruction.

DDogg

8th June 2004, 07:34

IMO, Q is a subjective metric for each movie. adding filters and/to compare Q, is extremely unmotivating, since it's mostly a bitrate comparison, not a visual quality indicator But that itself is a subjective statement because it implies a full understanding of what Q-Value, as used in CCE, is/does measure. This is a topic which I don't think anybody in this thread, including myself, has a real good understanding of. That is why I made the point that having and making strong theoretical opinions about something we don't really understand is a true exercise in frustration.

However, in some correspondence with Bach, he makes some interesting points that really back up parts of the several different opinions including yours, and it clearly refutes other opinions. Since learning more about something is always a good healing balm, I'll quote some of them for educational reference. It takes a couple of reads, but then it starts making a lot of sense.

Bach wrote to DDogg on 7th June 2004 13:37:
Please, forgive my grammar. It is a long time without English writing.

Let's try to enlighten this mess about Q factor.

Some points to take into account:

1) Q factor is NOT the quantization factor (qf), at least in the sense quantization factor is defined in MPEG2 compression. However, it is obvious that Q factor is proportional to QMF, so that it can be used as a measure of the "quality of compression" (QC). QC is as bad as higher is the quantization used in MPEG2 compression. So, shortly, the higher Q factor, the lower the QC.

2) QC is NOT the quality of the picture. It is the measure of how accurate is the MPEG2 compression. Lets get the flux of events:
source -> MPEG2 compression -> storage -> MPEG2 decompression -> target. You get the highest possible QC when source - target = 0. Lets call this difference as "MPEG2 artifact". The higher the amount of MPEG2 artifact, the lower the QC.

3) the most annoying "MPEG2 artifacts" are the mosquito noises caused by the lack of high frequency coefficients) and the so called "macroblock" or "checkerboard" pattern (caused by high quantization).

4) As a result of points 1, 2 and 3, we can say that "the higher the Q factor, the higher the amount of mosquito noise and checkerboard [macroblocks]".

Your aim while re-encoding is to achieve an accurate picture at first and a pleasant picture at second, using a given bitrate lower than the original. Using CCE and avisynth, the accuracy can be tweaked using mainly Q.factor (and a good matrix, but I will not talk about this now). The more pleasant look (is this the word?) is given by avisynth filters. For both aims, the disturbing and disgusting "mpeg artifacts" are things that you must avoid [at all costs].

Now, let's see why we must play with Q.factor as a measure of quality. It is easy to verify that "mpeg artifacts" are much, a lot, more disturbing than a slightly filtered picture. So, since Q.factor is the measure of "mpeg artifacts", you can use this Q.factor as a measure of quality, being the source filtered or not.

Lets assume you want (or need) to fit a given movie "LOTR_SPR_Plus" into 1 DVD. If you want to do it in a wise way, you will do in the following order:
1) try to re-encode without filter (your first aim is accuracy). If Q.factor is smaller than a given value (Q=40) your encoding is good and you are ok. If it is higher than this value, the quality is not good due to those disturbing mpeg artifacts. It is time to give up to accuracy...
2) filter this source, using avisynth filters, as far as you can, keeping the picture as pleasant as you want (you can preview this [percieved level of visual quality] using virtual dub). Re-encode. If Q.factor=40 or smaller, this means that your picture will be pleasant and you are ok. If not, you will get disturbing "mpeg artifacts" degrading the pleasant picture that you need. It is the time to downsize your frame.

once again: Q.factor is not a measure of the quality of the picture.
Picture's quality is a psychological measure, for which mpeg compression was not created to [deal] with. It is the user work to verify if a filter is apt to keep or not to keep the quality of a picture.

Q.factor is a measure of the QUALITY OF COMPRESSION, be it done with or without prefiltering.

Cheers.

/Add: Then when one uses a known filter set as a constant that does not appreciably degrade the video to the eye and couple this with a method to quantify the quality of compression, it is not a far stretch to suggest that a method of quantifying the quality of the video results in a somewhat, and admittedly, backhanded way.

Note one of the key points mentioned is that a filtered Q and an unfiltered Q ARE the same thing because Q is a measurement of compression quality, or put another way, Q is a measure of artifacts in the compressed stream yielded by the encoding mechanism. Lower Q means a lower amount of artifacts whether filtered, or not filtered.

toliman

8th June 2004, 10:51

i liken the Q factor as akin to measuring RPM, rather than the speed of the vehicle - the higher the Q, the more harshly that compression is applied to fit the desired bitrate.

when it takes on a quantifiable level, i.e. the differences between Q14 and Q20, i personally don't see that it's making a discernible difference, only that the encoder is working harder to fit material into the bitrate provided. but, that's my opinion on it. other people put more faith in Q factors to provide reputable results of filter strategies than i do.

(they perhaps know more about how filters effect the Quant. matrices, or the underlying DCT transforms in the specific encoders, or the specific strategies of each Q level, etc. and then there's the colour spaces involved, etc.)

my understanding is, filtering the video in stages that approximate the encoder's reduction strategies, reduces the complexity and allows for manipulation and control that the encoder does not allow you to make. like undot() for instance, reduces the complexity of macroblocks in a way that approximates the internal encoder stratgegies used to reduce bitrate. deen() is a lot harsher, iirc, applying spatial and temporal filtering to blocks and removing discrete changes in colours across uniform areas and areas that remain visually similar, i.e. noise.

the problem with using avisynth filters on DVD content is, that it isn't selective about which scenes should use filters and which scenes do not need it, it is applied uniformly throughout and reduces overall quality when it's not necessary or helpful to do so.

what i find more useful, are adaptive masks that work in scenes they work well at, e.g. luma and motion filters. The effects are usually cleaner and faster, as they are more selective about the visual areas they choose to process, enhancing compression selectively throughout the video, much like the encoder does intuitively.

of course, it takes a lot more processing to analyse and process than a simple uniform filter, which means more time, and the chance that the encoder will have it's own ideas on how to reduce bitrate, that the avisynth filters will make more difficult to achieve.

jdobbs

8th June 2004, 11:51

As for Q, I've always believed the the folks who wrote CCE understand it best. Here is a quote from the CCE 2.50 manual:

-------------
Specify the output picture by the Q. value in Q.factor and
Bitrate. Q. is a concept unique to Cinema Craft Encoder.
The range of the specification is 1 - 300. As the Q. value
becomes smaller, image quality improves, and as the value becomes
larger, higher compression is used. For the setting, refer
to the following.

Q.factor Description
1 - 40 Priority is given to image quality over compression rate
40 - 80 Standard setting
80 - 120 Priority is given to compression rate over image quality
120 - Image quality deteriorates considerably

- Specify the minimum bitrate in Quantization factor and
Bitrate. Specify the bitrate in kilobits/sec. units. The range
of the bitrate specification is 0 - 15 Mbps (0 - 9.8 Mbps for
the setting to conform to DVD).

The encoder executes encoding while adjusting image quality
such that the bitrate does not become lower than the value
specified here. If the specified value is 0, this means that the minimum bitrate is not specified.

- Specify the maximum bitrate in Quantization factor and
Bitrate. Specify the bitrate in kilobits/sec. units. The range
of the bitrate specification is 0.5 - 15 Mbps (0.5 - 9.8 Mbps
for the setting to conform to DVD).

-------------
Also, on the screen when you select it, it is in a box that is called "Quantization and Bitrate".

I think Q is just a value that determines the amount of quantization for CCE to attempt to achieve... then the necessary bitrate (within the range you've selected) is used to meet it. It is just a scale like all the other CCE settings. Everything else is urban legend.

[EDIT] Corrected a misprint, first setting of Q.factor Description should read "1 - 40" -- it was incorrectly shown as "1 - 4"

tylo

8th June 2004, 12:09

I think Bach is making a number of good points, but still there seems to be a few other hidden parameters that comes into play when determining the visual quality of an encoding.

Compressability of a movie is a product of many components:

- Source quality (cleaness, sharpness, ...)
- High-action / static source
- Color, vividness, contrasts
- Etc.

Given two movies M1, and M2 with the same resolution, and both same length to be fitted on same media size. M1 gets Q=30, M2 Q=50. Surprisingly, the encoded M2 may very well overall look better than M1, even if the sources M1 and M2 appears to be of about the same quality. How?

I recently encoded two PAL movies into one DVD. The last got size=2150mb, Q=59, no filters. I expected something bad, but to my surprise, it looked terrific - no noticable macroblocking or typical mpeg2 artifacts. I think I see some light "smearing", but not unpleasantly at all.

The source is of exceptional sharp and clean quality, fairly bright, and medium/low action (no high-action scenes).

My conclusion of this is that Q is not a pure messure of encoding quality, in the sense of the perceived quality it produces. In my case it gave a high Q, but no obvious macroblocking. Sometimes, I have got Q's in the thirties, but still macroblocked in high-action scenes (not because of max-bitrate contrains), which I perceive as lower quality encodings (although other aspects of the encoding may look good).

Nocturno

8th June 2004, 17:12

@evestorm

gripcrop (width=704,height=480,source_anamorphic=true,dest_anamorphic=true,overscan=2)

don't think there should be a space between gripcop and the (width=704.....)

sillKotscha

8th June 2004, 18:06

Originally posted by DDogg
Download this (http://forum.doom9.org/attachment.php?s=&postid=490683) and put in your avisynth plugin folder. [/B]

hi DDogg,

I'm looking for the readme of gripfit for a couple of days but couldn't find it. Now I saw you're proposing it here... maybe you can help me out and attach the readme here? That would be very kind of you. Thank you in advance (if possible :) )

cheers Sill

P.S. jdobbs, what you've written is just out of space ;) - DVD-RB is so cool/ such a great, great program - it's just lovely :rolleyes:

Mozart

8th June 2004, 18:38

Originally posted by tylo
... The last got size=2150mb, Q=59, no filters. I expected something bad, but to my surprise, it looked terrific - no noticable macroblocking or typical mpeg2 artifacts. I think I see some light "smearing", but not unpleasantly at all.

The source is of exceptional sharp and clean quality, fairly bright, and medium/low action (no high-action scenes).
[b]
Not so surprising, since the defaut is Q=60 and, as you said, the source is good enough (free of noise and etc).

[b] ...Sometimes, I have got Q's in the thirties, but still macroblocked in high-action scenes (not because of max-bitrate contrains), which I perceive as lower quality encodings (although other aspects of the encoding may look good).

I have got sometimes the same result and, guess what, the source was blocky at first.

Mozart

8th June 2004, 20:13

@Jdobbs

Wrote by Bach (myself before vanishment)
1) Q factor is NOT the quantization factor (qf), at least in the sense quantization factor is defined in MPEG2 compression. However, it is obvious that Q factor is proportional to qf ...

is it so hard to understand my english? Quantization factor have got some sinonimous along the time, but it still have the same meaning in the mpeg compression world. You can find the meaning of quantization factor in mpeg2 compression reading here (http://www.mpeg.org/MPEG/MSSG/tm5/Ch10/Ch10.html). In this page, quantization factor is called "quantization parameter" and assigned as "mquantj". Go ahead and see the other chapters in order to understand its usage.

Anyway, I've said "However, it is obvious that Q factor is proportional to qf (quantization factor)". Do you understand this? In math words, I've said that

Q.factor = f(x) * qf

but nor me neither you know if f(x) is a simple constant or is a function of an adaptative parameter created by CCE author. Given the CCE's manual hype about the uniqueness of Q.factor, the later is more likely.

Some mpeg encoders lets you use exactly the value of quantization factor. Get the windows version of ffmpeg and try an encoding using
-q 4 or -q 6. If you analize it (the encoding) with bitrate viewer or any other analyzer you will see a flat green line showing a constant quantization equal to 4 or equal to 6. Now, get CCE and do an encoding using Q.factor=40 and analyse using bitrate viewer. Is it showing a flat green line with a constant quantization equal to 4?

I do know very well the CCe manual, and I have just two questions about it for you?
1) from your quote, Q.factor is a unique concept of CCE. How the hell could it be unique if it was just plain quantization factor, which is used by ANY mpeg encoder?

2) given the mess between the definition of quantization factor (a mandatory feature of mpeg encoding) and Q.factor (a concept unique for CCE), and other messy explanations about their settings, do you think the manual writers and the program writers of CCE are the same guys :D?

I don't think you should get CCe manual to the letter.

jdobbs

8th June 2004, 21:57

@Mozart

Understand and agree with you 100%. My guess is that Q is not a part of the calculation at all, but is just used as an index into either a table of values or some calculation that equates to quantization that they've divided into a scale of 0-300 (as I said in my earlier response). I think what they mean by unique is just that -- it isn't the actual quantizing parameter (or it would be a strange value indeed). It very clearly, however, is the value that is used to determine quantizing level.

Either way, the point I have been trying to make is that it is the driver for quantization level (of that I am positive and which I think you agree) and that comparing two filters based upon the resulting Q value necessary to reach a certain output size (which is what happens in RoBa prediction) is not an accurate comparison of quality -- only of the amount of quantizing that is necessary based upon the modified input after the filter has been applied.

In other words I'm saying that:

If Q = 50 with output size = c using filter a, and Q = 40 with output size = c using filter b, that does not imply the quality of the output of filter b is better, only that less quantization is necessary after the filter.

I'm also saying that the specified Q is the driver that determines the acceptable quantization level to be used to calculate required bitrate in OPV in CCE.

Just a little off-topic, but, how many composers names are you using anyway?

[added] I'm also saying that a lower Q value that is realized after a filter has been applied does not necessarily indicate better quality than the original output (at a higher Q) without filtering. It is indicating a lower required quantization level on a modified source -- which isn't an apples-to-apples comparison.

Mozart

8th June 2004, 23:51

If Q = 50 with output size = c using filter a, and Q = 40 with output size = c using filter b, that does not imply the quality of the output of filter b is better, only that less quantization is necessary after the filter.

[added] I'm also saying that a lower Q value that is realized after a filter has been applied does not necessarily indicate better quality than the original output (at a higher Q) without filtering. It is indicating a lower required quantization level on a modified source -- which isn't an apples-to-apples comparison.

Agree, but only if the difference between the values of Q-filtered and Q-unfiltered is not so high and when both are below some threshold. For me, based only in the movies that I have reencoded, anything done with Q above of 40 (if SVCD) or above of 50 (if DVD) have so much mpeg artifact (mainly blocks and edge noise) to be comfortable with. And, from this threshold to higher, the correlation between Q factor and mpeg artifacts scales much more faster than bellow of it. I mean, You may not nottice any difference of quality between a Q=20(filtered) and a Q=40(unfiltered), but you can nottice an high difference of quality, due to the increasing amount of mpeg artifacts, between a Q=50(filtered) and a Q=70(unfiltered).

Note: assume that the filtered movie does not have visually disturbing degradation of picture. This way, the comparison will not be apple-to-apple yet, but apple-to-almost_apple ;)

about my nickname: I would like to keep using Bach. However, after my last diva attack, that account was somewhat blocked and it was necessary to reload Mozart.
BTW: I do not think I have two accounts and, as a result, I would be under forum rule restrictions, since I cannot use Bach's account and Mozart's account is older than that rule and was hibernating while Bach was active.

onesoul

9th June 2004, 02:29

Originally posted by Mozart
Note: assume that the filtered movie does not have visually disturbing degradation of picture. This way, the comparison will not be apple-to-apple yet, but apple-to-almost_apple ;) I see your point of the improved quality of the filtered reencoded movie by the Q value droped by 20 (because of macroblocks introduced by a reencode with no filters and bitrate constraints like you said). But it's hard for me to accept that this kind of filtering won't degrade original picture which can be acceptable (and better than the macroblocked unfiltered one) but still noticeable. Even if there was a "super filter" that would only remove noise (like mosquitos, contour noise, artifacts, blocks introduced by original mpeg encoding or even other noise in original film), it would hardly reduce the "Q" value in that amount (20). But that's only my noob opinion.

About the nick name, don't mind it, just keep it posted ;)

evestorm

11th June 2004, 14:07

Thanks to all who helped with the SPR.

I was able to get the quality I wanted. As it turns out, checksum errors dont occur if you have used the crc patch like you were suppose to...DOH!!!! I can be such a dumb ass.

Anyways...I did a 6 pass vbr with Undot().Deen()and the result was more blurred than I wanted. I then let DVD-RB do its thing with a 6 pass vbr with no additives or extra preservatives
;)

The result is very good. Thanks again for all who helped, and to jdobbs for such a great app.

E

dragongodz

11th June 2004, 16:16

if i may quietly throw my 2 cents in ?

what must be accepted aswell is that no 2 dvds/movies are the same. so while light filtering on dvd "A" gives imperceptable to the eye results but improves compressability dvd "B" will be different. dvd "B" may show perceptable degradation from filtering and/or not increase compressability to any great degree. also the choice of filter and its settings are another variable that can throw comparisons. example is DDog likes undot().deen() but i may prefer something else. so even if we did the exact same dvd the results would be different again. :)

so there is no general right answer to using filters or not. as i said sometimes it can be very useful and other times not, that decision needs to be made on a per dvd per personal preference decision.

DDogg

11th June 2004, 18:09

so there is no general right answer to using filters or not That is a very generic statement. I guess theoretically it is correct, but from a practical tool users perspective I would differ.

One of the reasons I spent so much time on this subject is because of a practical situation I run into. My spouse, like many of our significant others, resents the time I spend on this hobby. One of the things that makes me nuts is when we actually do get the time to sit down together to watch a movie I encoded and it turns out it has artifact problems. Man! That just ruins my whole evening when I get the 'wife look' :) We all know what that is! Well, most of us do at least.

I really dislike scanning a movie in advance for problems as it ruins the pleasure of viewing it without expecting certain scenes you remember from the scanning. I was looking for a quick and automated method that would ensure a good watchable quality 95% of the time for my viewing method.

I think I and others like R6D2 tested every filter and every advanced motion adaptive script out there. Some of them were good, some sucked, but invariable all were terribly, terribly slow, even on my XP3200 equivalent.

After many time consuming tests, the Undot().Deen() combo showed itself to be a combination that gave the highest speed with the most compression enhancement and invisible/least alteration effects on the video for my use. Like I said, there are many other alternatives, but my focus was to take the exorbitant time to research a combination method just ONE time so that I did NOT have to think about it much again. This was as close to a universal method that I could find where we know that no true universal method can exist.

So, just to clarify, I first watch the D2SRoBa sample runs in D2D, and now potentially the OPV prep stage in dvd-rb if I am interested in menus and extras (which I normally am not). If that Q is much above 28-32, I then do the same with undot().Deen() and view the sample files left by D2SRoBa to make sure the video looks clean and crisp. Doing this in dvd-rb is harder because the samples are deleted (I wish they were not).

If the sample runs show the Q still above 28-32, I then crop overscan with FitCD, FACAR, or GripFit to encode at a 704 width as a last ditch measure. That is how I got the low 20's Q for ROTK. This easy to do in d2d, but it is very difficult to do in dvd-rb if source is the original. (some ScreenShots) (http://forum.doom9.org/showthread.php?s=&threadid=76663&perpage=30&pagenumber=2)

The final encode for these more difficult encodes is normally OPV with a second standard bitrate based VBR pass where the VAF from the OPV pass is reused for a second to get optimized BR distribution.

To close, I have yet to find one single source that this method will not result in the best possible encode obtainable [to my eyes], but I certainly acknowledge that there probably are some that exist. Frankly I don't care too much about discussing theory when it is not coupled with practical use and a concurrent evaluation of the results. Too much like "how many angels can fit on the head of a pin".

I can see the results with my eyes and I always get the results I want to see with my own eyes. This is simply a practical tool-users perspective from someone who wants to get good encodes without having to think much about it anymore.

I did not know there was so much theoretical disagreement and thought this method could be further automated in dvd-rb as a form of AI to yield a one-click wonder for full backup that would give the same potential for quality that I get from D2SRoBa and DVD2SVCD's DVD movie only mode. The newest D2SRoBa has this conditional filtering built in. The conditional filter (whatever you specify) is automated when selected and kicks in only when your specified target Q can not be reached unfiltered. More great work from tylo, and just another thing I don't have to think about anymore when I want a HQ encode.

/Add: Seems like I remember from some source, maybe it was "TigerLand", that Deen may not be optimum for heavy 'director induced' grain. Since IIRC, SPR has this induced grain, Deen may not be the best filter for that source. I'll have to get off my butt and do it again to find out. If so, I'll report back.

dragongodz

11th June 2004, 19:10

That is a very generic statement
it was meant to be. there is no way to encompass every dvd released and compare their relative qualities etc.

I was looking for a quick and automated method that would ensure a good watchable quality 95% of the time for my viewing method.
This was as close to a universal method that I could find where we know that no true universal method can exist.
I have yet to find one single source that this method will not result in the best possible encode obtainable [to my eyes], but I certainly acknowledge that there probably are some that exist
which backsup what i said. you have found what is good for you with your dvds but that doesnt make it universally so. example is a very good/clean film transfer, filtering is more likly to reduce quality than do any improvement, while a less that great transfer(which yes seem to be the majority) may indeed gain from light filtering.

Frankly I don't care too much about discussing theory when it is not coupled with practical use and a concurrent evaluation of the results
I can see the results with my eyes and I always get the results I want to see with my own eyes.
huh ? of course its about practical use. as for concurrent evaluation well to have any conclusive results you would have to set up a varied selection of films/footage and a large group of people to blind test the results. 1 persons can prefer a few macro blocks over smoothed while another will prefer smoothed. so you may be happy with the results you see but that does not mean someone else will agree.

I did not know there was so much theoretical disagreement and thought this method could be further automated in dvd-rb as a form of AI to yield a one-click wonder for full backup
and i am in the wrong for pointing out the potential pitfalls of having this automated ?

you know you really take this sort of thing too personally. nobody is trying to beat up on you or anything just discuss differences of opinion. :)

DDogg

11th June 2004, 20:16

you know you really take this sort of thing too personally. nobody is trying to beat up on you or anything just discuss differences of opinion. You don't have the slightest idea what I take personal and what I don't, although I unquestionably do take that comment personal.

As for the post, I was simply doing a wrap up on the point of view I put forth, nothing more. I had been away a few days building up a new machine. I regret it started off something yet again.

If you got some impression I was upset with you, then please realize that was incorrect. Not upset at all, and I have gone out of my way to point out my opinions are based upon my eyes on my viewing method and was just attempting a discussion with you on the topic.

Whether it works for others is not my concern, but people should at least try it and make their own decisions based upon their own eyes instead of a theoretical discussion that may or may not be correct.

Anyway, I am well and truly done on the subject, at least here in this thread. Lol, I'm glad many will breath a sigh of relief, but I do think we covered some good ground and made some progress.

Ultimately we should have shifted to a next phase with a viewer test and such, but their seems to be some adversarial relationships at play and proper teamwork would be difficult. Perhaps another opportunity will present itself down the road.

ShadowKnight

12th June 2004, 02:19

well, I'm with DDogg on the filter subject. I've played around and burned a lot of time messing with tweaking my videos to look their best. I also find Undot.Deen to be a pretty universal compression method.
Having an option to automate this process would ultimately be ideal to make DVD-RB the ultimate in ease-of-HQ backups. Even just a simple way to sample a filter or two on the video, so you can try out what will work best for the source... that would be a power-users dream for these scenarios. Maybe coupling the Preview-mode with the Q-anylize stage would be a way to go, then perhaps you can run a q-test for the size, and then preview it. The only thing I dont like about the scenario is the current method of prepare then q-analyze. I'm not certain that you need to do the prapare every time unless you change options other than filters... I wouldnt think so. So all you need to do is have an advanced mode, with the prepare step seperate. After that is Preview/Anylize, where you plug in your filters, anylize for q-value, and preview the quality manualy (preferably with zooming capabilities).
Heck, I know it sounds like a lot of trouble, but think about the ease of use, and control over the output you'd have.
Even at the very least, or as a quick place to start, simply having the q-anylize pass left over for pre-viewing manually would be nice as well. Maybe that could be an advanced option Jdobbs?
Just putting in my two cents... I want this proggie to be all you need. Because that would be truly sweet indeed :)

dragongodz

12th June 2004, 06:58

DDog quotes and replies -
You don't have the slightest idea what I take personal and what I don't, although I unquestionably do take that comment personal.
well there is no insult meant to you and no malice yet you are getting worked up over someone disagreeing with you. whatever.

If you got some impression I was upset with you, then please realize that was incorrect.
fine but you still seem to be getting worked up over it all. ok you may not be but that is just how what you have written appears to me.

I have gone out of my way to point out my opinions are based upon my eyes on my viewing method and was just attempting a discussion with you on the topic.
as i was just trying to discuss that while i gree that filtering can be beneficial it can at times not be. also that different people prefer different end results. an example is evestorm prefering SPR without the filtering.

Whether it works for others is not my concern, but people should at least try it and make their own decisions based upon their own eyes instead of a theoretical discussion that may or may not be correct.
and if you reread what i said i agreed with the OPTION of filtering so people can test which they prefer per film etc. call it theory all you like but you have 1 example right here (SPR as already said) where the "theory" is proven correct to 1 person. before you say but thats just 1 person yes i know and i already said each person will have their own preferences on the results.

Anyway, I am well and truly done on the subject, at least here in this thread. Lol, I'm glad many will breath a sigh of relief, but I do think we covered some good ground and made some progress.
i agree, i am done aswell. i just do not need the agrevation. as for how much ground was covered, well only the future will tell. :)

Ultimately we should have shifted to a next phase with a viewer test and such, but their seems to be some adversarial relationships at play and proper teamwork would be difficult. Perhaps another opportunity will present itself down the road.
yes i did mention blind testing. its only adversarial if you think that i(not speaking for anyone else) disagree for the sake of diagreeing or oneupship. but yes i can easily see where teamwork would indeed be difficult to say the least.

ShadowKnight quotes and replies -
Having an option to automate this process would ultimately be ideal to make DVD-RB the ultimate in ease-of-HQ backups.
yes as an OPTION which is what i said. to have it automatically do filtering based on a CCE Q result is not the same thing.

Maybe coupling the Preview-mode with the Q-anylize stage would be a way to go, then perhaps you can run a q-test for the size, and then preview it.
agree. having DVD-RB do a sample( say 10x5 second clips from through the film ?) of unfiltered and filtered if a person desires so a person could then compare the results and choose which they prefered would be great.

think about the ease of use, and control over the output you'd have.
which was what i was also saying. users want to have some control especially with decisions that can improve or degrade the output. to automate it is to assume the program knows what your eyes will prefer. i think theres a little way to go before DVD-RB or CCE are that intelligent. :)

anyway as i said thats it. i really do have better things to do than keep trying to get some pretty simple ideas across for discussion.

DDogg

12th June 2004, 07:52

What a waste of space and effort.

wmansir

12th June 2004, 14:08

I shouldn't have to tell you guys to take a break from this and just let it go. Whenever the discussion is more about the posters than the topic it's a good time to re-evaluate, and I think we've crossed that point.

@All

Anyway, getting back on topic I thought I would provide a tip of the day. Here's a hack to make using filters a bit easier.

DVD-RB's current filter editor isn't exactly full featured. So, instead we are going to insert a call to a custom function, then we can edit that function very quickly to change our filter(s), or have it do nothing at all. The limitation is that it applies to all cells regardless, but the advantage is that it makes it super easy to use predefined filtersets, or custom filters, and change filters easily. And we never have to Tweak DVD-RB's Filter Editor settings.

Here's how:

[list=1]
First, we need to make our custom function. To start we create a file in our Avisynth Plugin directory (normally: C:\Program Files\Avisynth 2.5\Plugins\ ). It will be a simple text file called "MyFilters.avsi".

Next, we define our function and some presets. Here's an example:function MyFilter(clip v1) {
Return v1
}

function Undeen(clip theClip){
LoadPlugin("C:\easyenc\gordia~2\undot.dll")
LoadPlugin("C:\easyenc\gordia~2\deen.dll")
Return theClip.Undot().Deen()
}

Function FluxIt(clip theClip,int tThresh,int sThresh) {
LoadPlugin("C:\easyenc\gordia~2\Fluxsmooth.dll")
Return theClip.FluxSmooth(tThresh,sThresh)
}
Currently, our filter is setup to do nothing.

Next, we go in to the DVD-RB Filter Editor and add the single line

MyFilter()

For convience you can make a shortcut to edit your MyFilter.avsi file. Make a shortcut with the command:

notepad.exe "C:\Program Files\AviSynth 2.5\plugins\myfilter.avsi"
or the text editor of your choice. You can put it with your DVD-RB shortcuts on your quickstart or start menu, or just in with the DVD-RB folder, wherever you work from.

Now, to use the filter we just edit the MyFilter function. In my example We could change it to be:

Return v1.UnDeen()

or

Return v1.FluxIt(5,5)

or we could make a completely custom filter:

v1.SeparateFields()
FlipVertical()
ComplementParity()
Reverse()
Weave()
TurnLeft()
FlipHorizontal()
Reverse()
Turnleft()
SwapFields()

After we save, the next time an .avs script is opened with a call to MyFilter() the new function will be called.

Of course we can also call the presets (UnDeen, FluxIt, ect) directly when we edit scripts individually or when using a multi-file avs editor like RB-Opt.

[/list=1]