Saving Private Ryan

[evestorm]

Ok this is the big test and I want it to come out as best it can.
Has anyone backed up Saving Private Ryan R1? I am about to attempt it tonight. If anyone has, please post your settings. Even if you haven't backed it up, please post reccomendations.

Thanks

E

[evestorm]

Forgot, I am using
CCE SP 2.5

I am thinking

VBR_Bias 30
Quality_prec 25
maybe 4 or 5 passes.

I have trouble being able to tell when I have gone overboard with the number of passes. I did, "The Ring" R1 earlier this month using just two passes and it came out looking decent, but noticably blocky.

E

[Fr4nz]

Originally posted by evestorm
[B]Forgot, I am using
CCE SP 2.5

I am thinking

VBR_Bias 30
Quality_prec 25
maybe 4 or 5 passes.


These settings aren't good!

VBR_bias is too high, (higher values makes CCE to distribute the bit-rate in a more uniform way). For SPR I'd suggest a vbr_bias of 17-18.

Also Quality_prec is too high (high values tends to give more detail to "flat" parts, that don't have much detail, while low values tend to give more detail to detailed parts of the image). I'd suggest 16-17 in this case.

3 passes are enough...do 4-5 passes only if you have extra-time...but I think you'll never be able to notice the difference from 3 to 4 passes.

Anyway for normal movies (lenght =< 2 hours) vbr_bias 20/25 and quality_prec 15/16 are good values!

[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.

[ShadowKnight]

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]

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]

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]

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]

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]

In CCE 2.50 the Q factor is "vbr_bias"?

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

[Noah]

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

[jdobbs]

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]

Originally posted by Noah
No

So Q isn't present in 2.50, right?

[evestorm]

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

Ouch. Any settings I should check?

E

[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.

[jdobbs]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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