Saving Private Ryan

[Fishman0919]

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

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

What a waste of space and effort.

[wmansir]

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]

[nashcity]

I know its been a long time since this thread was re-visited, but I am about to encode Saving Private Ryan and I was wondering if anyone had any ideas on the best way of doing so. I would love to hear info about filters, matrices, etc.... that really did a good job. So far, I'm thinking about Undot().FluxsmoothT() at the very least.

Thanks for any info!!!!

[jdobbs]

I personally did it with all defaults.

[Voodoochild]

So far, I'm thinking about Undot().FluxsmoothT() at the very least.
Thanks for any info!!!!

with UnDot you want see any difference FluxsmoothT() will make it less grainy, but grainy is part of this movie art as I see it. Still if you want to remove grains you can also use removegrain(5) (work faster) or even hqdn3d(2.0). I personally think this movie should stay as is.
I did it with CCEAQM=1 and cce default matrix * 0.75, which make it retains more details. avamat 6 (3500-9500) is also good matrix for this movie. This movie has very high BR, but it's long full of action, shaky camera movements and grains :-), a nightmare for encoders. so higher matrix are not so good for it in manner of compression