Is converting DVDs to AVC a good idea?

[R3Z]

/snip

Absolutely great post mate :thanks:

I have basically came to the same conclusions you have but reading a post like yours would have saved me lots of time.

I beg any newbies to read Morte66's post several times :)

[frodeste]

Re Mass DVD conversion for media server...
...

Great! Have you created a profile in MeGUI that you can share with us? Or the commandline for encoding the video?

[Morte66]

Great! Have you created a profile in MeGUI that you can share with us? Or the commandline for encoding the video?

Here are some x264 settings based on a suggestion from Saggittaire, that are as close as I've come to "optimum bang-per-buck":

--crf 22 --bframe 2 --weightb --ref 2 --direct auto --filter -2:-2 --crf 26 --qcomp 0.75 --ipratio 1.25 --pbratio 1.33 --analyse "all" --8x8dct --me "hex" --subme 5 --progress -o

You could add an anti-blocking matrix with them if you want.


Now here are the settings I actually use. They're maybe half the speed for only 25% more compression, but they suit me fine because they encode about 3 DVDs/day, which is as fast as I want to do all the ripping and preparation etc.

Here's my MeGUI video encoder profile (http://www.joel-benford.co.uk/post/crf 22 -2-2 cqm antiblock.xml); and here's the x264 command line:

C:\Program Files\MeGUI\tools\x264\x264.exe --crf 22 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct none --filter -2,-2 --subme 6 --analyse all --8x8dct --ipratio 1.0 --threads 2 --thread-input --cqmfile "C:\Program Files\MeGUI\extra\M4G-V3.cfg" --progress --no-psnr --output "" ""

Here (http://www.joel-benford.co.uk/posts/M4G-V3.cfg) is the custom anti-blocking matrix I'm using. I find that does the job, but MP4-Guy (who wrote it) may have an improved version by now.

[akupenguin]

--crf 22 ... --crf 26
typo.

[frodeste]

..Here (http://www.joel-benford.co.uk/posts/M4G-V3.cfg) is the custom anti-blocking matrix I'm using. I find that does the job, but MP4-Guy (who wrote it) may have an improved version by now.
Interesseting.

I downloaded this "M4G High Detail 3.1" the other day from the forum (This thread). Any idea about how they compare to the one you mentioned??
I looked for an updated M4G-V3, but did not find any.

I will test your profile tomorrow with the different matrixes, after the current encoding is complete.

My test last night was okey, producing quite a small file but I think the image could be sharper. Given that I am not resizing my video, how can I set MeGUI up to give me a sharper image? In the AVIsynth file?

edit: I have read up on the subject, and see I can tweak settings in MeGUI. Great info to be read in the Forum :) Anyhow, I can see how I need more input on using AVIsynth configs also. Do you or any others add any filters to AVIsynth that improve sharpness?

[Morte66]

typo.

Yup, sorry. Only needs the 22.

[*.mp4 guy]

M4G V3 hasn't been updated, and it isn't the same thing as M4G high detail 3.1.

[Morte66]

Interesseting.

I downloaded this "M4G High Detail 3.1" the other day from the forum (This thread). Any idea about how they compare to the one you mentioned??

In technical terms, no idea. I just download stuff and keep it if I like what it does. :) I think of M4G as a stronger version of the other one -- more effective anti-blocking, at the cost of extra bitrate.

Anyhow, if you're down to two choices you shouldn't be asking me. There's a lot of personal preference in this, plus it depends on the characteristics of your monitor. Try 'em both on a couple of short clips and see what you like. Put something like "trim(5000,6000)" in your avisynth script, that'll give you about 40 seconds to test.

Given that I am not resizing my video, how can I set MeGUI up to give me a sharper image? In the AVIsynth file?

Three things you can do:

- Turn down the deblocking in x264, which you can set in MeGUI. A lot of the standard MeGUI profiles use (-2,-1) which I find soft. I like (-2,-2) personally, which seems to be towards towards the sharp end of what people at Doom9 use. You could try taking it down as far as (-3,-3), but test that thoroughly before you make a habit of it. You seem to need higher quality settings to get away with lower deblocking settings.

- Use sharpening in your player. I do this with ZoomPlayer and the ffdshow post-processor.

- Use sharpening filters in Avisynth. I don't use this, because the "preferred" sharpening will change if you change monitors and once it's in the encode you can't change your mind. Also I think you should sharpen the resized image, or use a resizer that sharpens, so you need to do it during playback. [Not everyone agrees on that last bit.]

[frodeste]

M4G V3 hasn't been updated, and it isn't the same thing as M4G high detail 3.1.
:thanks: this is good to know.

[frodeste]

... Put something like "trim(5000,6000)" in your avisynth script, that'll give you about 40 seconds to test.
Good point.
Three things you can do:

- Turn down the deblocking in x264, which you can set in MeGUI. A lot of the standard MeGUI profiles use (-2,-1) which I find soft. I like (-2,-2) personally, which seems to be towards towards the sharp end of what people at Doom9 use. You could try taking it down as far as (-3,-3), but test that thoroughly before you make a habit of it. You seem to need higher quality settings to get away with lower deblocking settings.

- Use sharpening in your player. I do this with ZoomPlayer and the ffdshow post-processor.

- Use sharpening filters in Avisynth. I don't use this, because the "preferred" sharpening will change if you change monitors and once it's in the encode you can't change your mind. Also I think you should sharpen the resized image, or use a resizer that sharpens, so you need to do it during playback. [Not everyone agrees on that last bit.]

I agree on the sharpen while playing idea, as this does not affekt the material. I have done many test now, and find that using x264.exe --qp 18 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct --me umh --threads 2 --thread-input --progress --no-psnr --output gives me a great sharp transparent output, at about 1/2 the original file size. I will test some more, as I am aiming for the same quality at around 1/4 the original size. (Give or take)

Running your profile tests next.

[Morte66]

I have done many test now, and find that using x264.exe --qp 18 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct --me umh --threads 2 --thread-input --progress --no-psnr --output gives me a great sharp transparent output, at about 1/2 the original file size. I will test some more, as I am aiming for the same quality at around 1/4 the original size. (Give or take)

You'll probably have to drop the crf level (say 20) to get the size down that far. There's only so much additional compression you can get with advanced settings.

If that's not satisfactory, and you stay at half the original size, then Xvid in constant quantiser mode with q=2 is a very strong alternative to x264.

Might I suggest also trying something like --filter -2,-2 or --filter -3,-2. It seems to me that turning down the x264 in-loop deblocking is a more efficient route to sharpness than turning up the overall quality level.

Running your profile tests next.

When you do, try turning off B-Frame prediction (--direct none).

Are you actually seeing flickery blocks in large dark areas? That's what the profiles will help with. If you don't have the problem, they'll just put the bitrate up for no gain.

[frodeste]

A few observations.

--crf 22 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo
--bime --weightb --direct none --filter -2,-2 --subme 6 --analyse all --8x8dct
--ipratio 1.0 --vbv-maxrate 25000 --threads 2 --thread-inputGave me 7.79 fps, 1718 kbit/s file. I like the quality.

--crf 22 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo
--bime --weightb --direct none --filter -2,-2 --subme 6 --analyse all --8x8dct
--ipratio 1.0 --vbv-maxrate 25000 --me umh --threads 2 --thread-inputGave me 6.16 fps, 1707.55 kb/s file. I can't tell the difference between the two. 7.79 to 6.16 will increase encoding time more then it is worth.

--crf 22 --ref 10 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo
--bime --weightb --direct none --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct
--ipratio 1.0 --vbv-maxrate 25000 --threads 2 --thread-input Gave me 5.73 fps, 1730.50 kb/s. Still can't see any major difference.

--crf 20 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo
--bime --weightb --direct none --filter -2,-2 --subme 6 --analyse all --8x8dct
--ipratio 1.0 --vbv-maxrate 25000 --threads 2 --thread-inputGave me 7.08 fps, 2414.00 kb/s. Quality is better, but not obviously so. Even when I scale the picture up a lot while playing.

All test were ran with the MP4guy's matrix as mentioned above.

Running the first test again with no matrix, produced more or less identical results regarding visual quality, at 8.00 fps, 1587.13 kb/s (as to be expected)

Running the first test again twice - with and without custom matrix - this time with directional AUTO gave 9.02 fps, 1556.62 kb/s and 8.98 fps, 1483.90 kb/s respectively.
--crf 22 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo
--bime --weightb --direct auto --filter -2,-2 --subme 6 --analyse all --8x8dct
--ipratio 1.0 --vbv-maxrate 25000 --threads 2 --thread-input Again, I am satisfied with the quality, but the filesize is significatly smaller for both tests. Is this to be expected from turning on direct?

As you can read, I went with Morte66's filter settings, with makes me happy as far as sharpness goes. It's not perfect, but acceptable given the original material and bitrate. Thanks!

I realize that one can't draw a general conclution here. I find that using the matrix will produce larger files (as expected) and in this case only minor quality changes.

My conclusion so far, is to continue using the matrix with the following options.
--crf 22 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo
--bime --weightb --direct auto --filter -2,-2 --subme 6 --analyse all --8x8dct
--ipratio 1.0 --vbv-maxrate 25000 --threads 2 --thread-input --progress --no-psnrFor this test material, I am hitting about 1500 kb/s sec. Still somewhat higher than I am looking for (around 1300+/-), but quality is more important to me the diskspace. (Up to a certain point)

What other options could I go with to lower the bitrates? Options to my AVIsynth scripts are also of interest. I am reading a lot about how to make the source material more "compressible". Important note: I don't really care how long it takes to run encoding.

Are you actually seeing flickery blocks in large dark areas? That's what the profiles will help with. If you don't have the problem, they'll just put the bitrate up for no gain. No, I do not have this problem.

[Morte66]

Your results seem pretty similar to mine, except that I'd guess my display hardware/settings are harder on blocking than yours.

What other options could I go with to lower the bitrates?

If you're not suffering blocking that bothers you, try losing the custom matrix or use the milder "high detail" matrix. Make sure you test with some scenes with steady dark backgrounds.

Options to my AVIsynth scripts are also of interest. I am reading a lot about how to make the source material more "compressible". Important note: I don't really care how long it takes to run encoding.

Running a denoiser before x264 (which does lots of denoising itself) will give you a smaller file, but they potentially remove some detail. I don't generally use them, so I'm not familiar with the newest stuff. But try putting FluxSmoothST(10,15) in your avisynth script and see what you think. If you like what it does, check out newer denoisers like RemoveGrain and FRFun (start with searches in the AviSynth Usage forum).

[akupenguin]

Again, I am satisfied with the quality, but the filesize is significatly smaller for both tests. Is this to be expected from turning on direct?
Yes. direct=none is a huge penalty, and destroys a large portion of the purpose of B-frames.
Some people dislike the direct mode decision that x264 makes in certain scenes. Completely disabling direct mode does prevent that, but with lots of collateral damage in the form of increased bitrate everywhere else.

[Manao]

--ipratio 1.0 : I can't think of any good reason to do that

--ref 5 : You could lower that down to 3 or even 2 without seeing any quality loss nor bitrate increase. The encoding time, however, will improve.

[Morte66]

Yes. direct=none is a huge penalty, and destroys a large portion of the purpose of B-frames.
Some people dislike the direct mode decision that x264 makes in certain scenes. Completely disabling direct mode does prevent that, but with lots of collateral damage in the form of increased bitrate everywhere else.

Fair point. It's part of my extreme anti-blocking approach, tailored to my display which is very revealing of blocking. Since Frodeste isn't bothered by blocking, direct=auto would be the way to go.

[Morte66]

--ipratio 1.0 : I can't think of any good reason to do that

Come to think of it, nor can I. It seems to have crept into my encoder profile. Oops.

--ref 5 : You could lower that down to 3 or even 2 without seeing any quality loss nor bitrate increase. The encoding time, however, will improve.

Well, I did get some drop in file size for crf test encodes with 5 mixed refs instead of 3. Not much, and it's not especially good value, but like I said these settings don't try to be optimal value. They're the settings which get stuff encoded about as fast as I feel like ripping it. Though I guess I did do my tests about a hundred x264 versions ago, so maybe they could use some re-checking.

[*.mp4 guy]

Yes. direct=none is a huge penalty, and destroys a large portion of the purpose of B-frames.
Some people dislike the direct mode decision that x264 makes in certain scenes. Completely disabling direct mode does prevent that, but with lots of collateral damage in the form of increased bitrate everywhere else.

Actually, the problem isn't so much that X264 makes bad decisons with direct auto, using the standard matrix. The problem is that X264 is a bit finnicky about matrixes, and the more they differ from the standard matrix, the more likely X264 is to make bad decisions using direct auto. Luckily its not as huge a compressability killer as you would think, when it is working correctly it increases efficiency by about 7.5% (in my experience). When its not working well it can cause huge "eficiency" gains, but at the cost of very noticible blocking and temporal incongruencies.

[Manao]

But you could easily scale your matrices in order to get the same size as the flat matrix. That would (mostly) avoid those bad decisions. After all, we're not in the ASP case were a 'six of nine' concept allowed to invent missing quantizers between 2 and 3. With AVC, the matrices 16,16.... 16 and 24,24... 24 behave in the same way for the rate control.

[*.mp4 guy]

The problem isn't that the matrix is a different compressability then the standard one, so much as I can tell. The problem is that the DC coeficient is very low compared to the standard matrix, or atleast thats the best idea I've been able to get of what the problem is. Anyway, the matrix in question already uses values all the way up to 255, so scaling isn't an option.

[Sharktooth]

My EQM AVC-HR matrix has unbalanced coefficients to take care of the blocking nature of the AVC codecs.
It surely may screw decisions but you gain a more crisp and non-blocky picture comparing to the standard flat quantization.
Well, it may be improved and maybe balanced not screw so much the RC, but i have no time for that (it requires a s**tload of consecutive tests).

[*.mp4 guy]

Yeah, the amount of testing required is a pain in the ass, especialy considering that linear scaling of all coeficients is something the codec should be able to do easily. Also It's very hard to test whether the compressability of a matrix is balanced when the rc can't even keep cq encodes acting normaly, you will notice that with direct mode auto my matrix has similar compressability to the standard one, the matrix was originally made before direct mode could be set to none, so as far as I could tell it was balanced. to make matters worse direct mode auto is only a problem on some sources, while it works fine on others.

[edit]
I should mention that this isn't supposed to be critisim of X264, it is after all still in alpha status, and problems like this are to be expected until X264 has been around long enough to hit 1.0.

[frodeste]

A lot of good comments guys! :thanks:

I have been reading up on the ipratio and ref settings. I have some understanding of ipratio, but not how this will change quality of the encoded material?

I see one of Sharktooth's profile changes ref to 15. Any reason for this? I find increasing this decreases the encoding speed, with I can live with if the quality is improved.

I also read a thread about increasing the number i b frames. Is this common?

I did another test with: -crf 22 --ref 10 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --ipratio 1.0 --vbv-maxrate 25000 --me umh --threads 2 --thread-input --cqmfile

This gave me 6.35 fps, 970.06 kb/s, with is somewhat lower framerate then what I am looking for, but the quality was ok for most parts of the move. Some scenes with stronge white light through a window in a dark room showed a lot of blocks.

What I am trying to learn here, is what effect I can expect from M.E Algorithm and Trellis. Your comments help me understand what I see when I change the different settings!

[frodeste]

I have done som more testing. Increasing or decreasing the reference frames does have som effect, but mostly on the encoding time. Nero does not like a large amount of reference frames. The source starts to stagger in certain parts of the picture.

Going from RDO to RDO level 2 does not seem to give much more quality but does increase encoding time, so I am sticking with RDO.

I have tested some with different types of ME Algorigthm, and will stick with --me umh for now.

Several testings shows me that I am getting lower bitrates for the whole movie then I get for about 40 seconds, so I have increased the quality somewhat to --crf 21 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh

I feel I am getting close to a setup that works well, gives me great quality, and encodes to a decent rate.

Just thought you might like to know.

Edit: The above settings seems to give me a bitrate in the range I was looking for, and is encoding quite quickly (~7 fps). I expect quality to come out better then for --crf 22. Which option should I test to achieve better quality? I need some help on what parameters will have the most effect (one way or the other).

[*.mp4 guy]

You could drop trellis and increase refs to 8, that would prolly put you ahead in both quality and speed, otherwise those settings are about as good as you can get right now without getting into non-objective territorry.

[frodeste]

You could drop trellis and increase refs to 8, that would prolly put you ahead in both quality and speed, otherwise those settings are about as good as you can get right now without getting into non-objective territorry.
Great! I'll try it out.

[akupenguin]

trellis is fast (except at very high bitrates). refs are slower, and ref=5 is already well into diminishing returns for most content.

[*.mp4 guy]

Ehh, sorry about that, I think I confused trellis with rdo mode 2.

[frodeste]

Okey. More testing completed.

--crf 21 --ref 8 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads 2 --thread-input --sar 37:25 --cqmfile "M4G High Detail 3.1.cfg" --progress --no-psnr
encoded 162990 frames, 6.97 fps, 1146.03 kb/s

--crf 21 --ref 8 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --trellis 2 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads 2 --thread-input --sar 37:25 --cqmfile "M4G High Detail 3.1.cfg" --progress --no-psnr
encoded 162990 frames, 5.87 fps, 1111.39 kb/s

--crf 21 --ref 8 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me esa --threads 2 --thread-input --sar 37:25 --cqmfile "M4G High Detail 3.1.cfg" --progress --no-psnr encoded 162990 frames, 2.66 fps, 1155.63 kb/s

--crf 21 --ref 8 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --trellis 2 --analyse all --8x8dct --vbv-maxrate 25000 --me esa --threads 2 --thread-input --sar 37:25 --cqmfile "M4G High Detail 3.1.cfg" --progress --no-psnr
encoded 162990 frames, 2.55 fps, 1111.90 kb/s

What I can conclude is:

Using Trellis from none to always slows down the encoding from ~7 to ~6 fps. It seems that the files are smaller when using trellis without effecting quality, so I am sticking with it.

I am also keeping the number of ref frames at 8, as I am getting good encodingspeeds. I don't think I have much to gain from more referance frames.

The real drop in encoding time comes from changing ME Algorithm from Multihex to exhaustive. I honestly can't see much difference between the two, so I will stick with using the Multihex setting.


Since this setting is producing close to transparent encodes for me at acceptable bitrates, I have started testing with better quality (crf) settings. My understanding is that lowering the crf value from 21 to 18, will on avarage increase bitrates and (in theory) better quality encodes. Is this correct? At least, this is what I see from my testing. I also see a drop in encoding speed.

But for the time beeing, here is my "own" personal profile setting - hopefully to help anyone starting out with x264:
x264.exe --crf 21 --ref 8 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --trellis 2 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads 2 --thread-input --cqmfile "M4G High Detail 3.1.cfg" --progress --no-psnr --output "" ""

If anyone cares to comment my choice of settings, feel free.

I have spent a great deal amount of time trying to find the cross between encoding speed, avarage bitrate of resulting file, all while producing what I perceive to be a transparent encode. I think I have come close to this, with your help. So I think a :thanks: is in order.

[xyloy]

x264.exe --crf 21 --ref 8 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --trellis 2 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads 2 --thread-input --cqmfile "M4G High Detail 3.1.cfg" --progress --no-psnr --output "" ""
The deblocking filter is adaptive. So 2,2 is not a good idea if you want to preserve details. And 2,2 would be at least a little meaningfull at extremly low quality(let's say a range of q40 <---> q51) on anime encodes, but not at all with --crf 18/22/26 and so on.

Besides --no-fast-pskip, --no-dct-decimate would be a good add for "transparent encoding".

You can also disable SSIM computation ( --no-ssim) if you don't use it(SSIM and PSNR computation are alike)

[nm]

The deblocking filter is adaptive. So 2,2 is not a good idea if you want to preserve details. And 2,2 would be at least a little meaningfull at extremly low quality(let's say a range of q40 <---> q51) on anime encodes, but not at all with --crf 18/22/26 and so on.
Um, he's using -2,-2, which is reasonable.

[unmei]

My understanding is that lowering the crf value from 21 to 18, will on avarage increase bitrates and (in theory) better quality encodes. Is this correct? At least, this is what I see from my testing.
Since the bitrate part is an observation and not an interpretation, it must be correct :)
Now to the interpretation:
The CRF value is similar to the quantiser in constant quantizer mode, except is not really a quantiser but sort of a "quality" parameter scaled in a way that it about represents the resulting average quantiser. Therefore higher CRF implies a higher average quantiser. And the higher the quantiser, the more data is dropped out of a block's frequency components. Even tho quality in this step is not strictly proportional to data kept, less kept frequency data usually implies less quality (when only looking at this step of course).

I also see a drop in encoding speed.
This stems (at least for a large part, i guess) from the lossless coding at the end (CABAC or CAVLC) having to compress more data.

[frodeste]

Um, he's using -2,-2, which is reasonable.
I did tests with lower settings, but found the resulting movie to not be so sharp as I like.

But point taken on both sides.

[frodeste]

Besides --no-fast-pskip, --no-dct-decimate would be a good add for "transparent encoding".

You can also disable SSIM computation ( --no-ssim) if you don't use it(SSIM and PSNR computation are alike)

I read the other thread on this with great interest. However, I can't see that turning on (Off) the SSIM in MeGUI changes the actual command line. Could this be a bug?

[dumbas..]

Well as a admitted total novice... to throw some fat on the fire...:devil: And lay myself bear to riddicle.....

This thread started by implying, without asking what is <hesitate> "best". Mpeg4 AVC vs the MPEG2 standard. For DVD's to another format.

comomolo - disagree if you feel this is an incorrect interpretation.

I have to concure in general. I have found that AVC gives me the most pleasing solution. However I retain the original DVD for future reference should (when) a better re-encoding solution appears.

Various answers appear with the 'owner' implying what they believe to be "best" for them. This is all ok by me. I am glad for the insight.
What seems to be happening is that the symantics of superior knowledge end in a battle of X264 options. Then being used in a gladiatorial contest to mark what is "best" without , of course, saying that. Because we all have bests!

My point being what is best for one (person or movie) is not best for another. There ARE no correct solutions. Please guys, remember the idiots like me who just look for help and get lost in your trading blows of --xx this --yy that.

I would love to have your in depth knowledge of the ins and outs of the codecs. I am just happy to encode and get good results.:)

DVD to avc/ac3 .mkv using Sharktooth's 'slow' profile
HD to avc/ac3 .mkv trying Sharktooth's 'SA-HD-DVD' proflie.

Thank you Sharktooth - so much!

Of course, in a sense profiles suggest a best. What I hope is that the blow trading will result in imprvement to exellent programs like MeGui. To help the less able majority , like me to get the er, best for us!

I think time to encode is a red herring. Its only an issue if your are constanlty watching it and hoping to shave a few minutes of it. A new processor and bingo- in time, we all eventually have more power. I remember pentium2 taking 6-8 to do a DVD to DIVX. Now its 18 hrs to do HD to h264. The issue is achieveing better quality at the cost of more horsepower. Running as a background on my A64 3200 I can still watch X264 re-encoded HD with MPC+Fdshow using my projector on 109"screen. The results are brilliant. Thanks, I guess to you.

File size per say, is no longer an issue. Just how tightly you clutch you wallet! CD / DVD / Hard disk it just doen to money. A new disc format and bingo, eventually we all start using that more and more. Remember 5.25 & 3.5inch diskeettes?


There are, as I see it basically two limitations at stake.

Media size. Do I use CD or DVD and shrink onto? (DVD9 source or HD stream) and hence quality constrianed.

Quality. No reasonable real size contraint (Size constraint yes, but only to the extent of the media. In hone media server terms this is almost meaning less. ).

You either vote quality or file size. Pick any one!

I started reading this thread with great interest now I'm lost and confused! I would have thought that all this grey matter should combine forces:
Use a predefined source material. ( Just don't get to lost in defining a source - as I have witnessed elsewhere!)
Do your stuff.
Produce an output.
Let the great unwashed vote.
The "winner" could the be promoted to a profile?

It would then be available to duffers like me (and I suspect 80% of the people who use this forum.

Lets harmess all this ability guys, not trade codec --option blows!

I will now hide behind the sofa and wait to be flamed...:p

[frodeste]

Why flame? :)

I see your point. My motivation was learning about the options, so I understand what I need to tweak in each movie I encode.

I now have a setting which works very well for me, and I know what to change in the "special cases". The settings I have now, I call "My profile".

One of the reasons I started searching for my own settings, was that the HQ-Insane profile, created movies with stuttering in Nero and CyberLink. Hence, quality was crap.

My goal for finding a profile was, in priority:
1. ~transparent encoding
2. ~1/4 to 1/5 disk space saving. (RAID controllers don't come cheap)
3. Reasonable encoding speed. max 12 hours.

I have that now, and am very happy. I can batch encode the video, extract chapter files and so on. The only thing I can't get to work are subtitles. But that will be another thread.

[Jay Bee]

Lets harmess all this ability guys, not trade codec --option blows!

:D
....

[dumbas..]

Why flame? :)

Not meant as a flame just a "frustration".

-I see many threads that "drop" to a trade off between posters.. that have different views of what is "best" in their view. It never seems to reach a conclusion. Folks just get tired of posting replies.

I just wanted to see an objective output of the discussion. I.E. help the idiots like me, who look for guidance to achieve improved encoding, But without the greater knowledge of people who can tweak the process.

Profiles are what make x264 tick better?

My apologies if any offence was caused, or implied. But being contentious never comes free.

I LOVE this forum. It has greatly helped me achieve backups that I would never thought achievable, and I admire its coding contributors greatly.

[frodeste]

Not meant as a flame just a "frustration".

-I see many threads that "drop" to a trade off between posters.. that have different views of what is "best" in their view. It never seems to reach a conclusion. Folks just get tired of posting replies.

I just wanted to see an objective output of the discussion. I.E. help the idiots like me, who look for guidance to achieve improved encoding, But without the greater knowledge of people who can tweak the process.

Profiles are what make x264 tick better?

My apologies if any offence was caused, or implied. But being contentious never comes free.

I LOVE this forum. It has greatly helped me achieve backups that I would never thought achievable, and I admire its coding contributors greatly.

I did understand you, no offence caused to me :)

I also agree on your posting, hence I said why flame. But I do like this discussion.

An objective what's best is hard to do. That is what I was aiming for in my tests. On the subjecive side, well that's another matter.

[Thunderbolt8]

7) In the long run, I've averaged about 10MB/minute for 720x576 pixel DVD encodes using x264 on my crf 22 anti-blocking settings. I encode at about 7.5fps on a A64 X2 3800+. The encodes look better than the originals -- I gain far more from the Avisynth ColorMatrix filter and x264's inherent de-noising (noise desaturates colours) than I lose in the borderline-transparent compression.

do you mean the encoding time with 10mb/minute or the output file size ? if the latter, the one of the whole container, or only of the video stream ?
I used the same command line you posted there + same matrix (apart from the denoising thing, couldnt find where you configured that), but my filesize for Dr.No for example (105 mins, PAL 720x576 clever anamorph encoding with encode non-mode 16) is like 1,5 GB large (videostream only), although it should be like 1050 MB according to your statement. what am I doing wrong ?
where to find that inherent de-noising (noise desaturates colours) btw ?

[frodeste]

do you mean the encoding time with 10mb/minute or the output file size ? if the latter, the one of the whole container, or only of the video stream ?
I used the same command line you posted there + same matrix (apart from the denoising thing, couldnt find where you configured that), but my filesize for Dr.No for example (105 mins, PAL 720x576 clever anamorph encoding with encode non-mode 16) is like 1,5 GB large (videostream only), although it should be like 1050 MB according to your statement. what am I doing wrong ?
where to find that inherent de-noising (noise desaturates colours) btw ?

Filesize will vary because you are encoding using a "fixed quality" setting.
In some cases, I get around 1100 in bitrate, in others I get 1500, all depending on the material.

The denoising can be done in your avisynth script.

[Thunderbolt8]

Filesize will vary because you are encoding using a "fixed quality" setting.
In some cases, I get around 1100 in bitrate, in others I get 1500, all depending on the material.

The denoising can be done in your avisynth script.
im newb on that field, so could you plz elaborate which one and how to modify it ? it is really the same morte66 meant, since he spoke from the x264 "inherent" denoising, so not sure if he meant the avisynth script ?

I also used your latest posted settings here (x264.exe --crf 21 --ref 8 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-2 --subme 6 --trellis 2 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads 2 --thread-input --cqmfile "M4G High Detail 3.1.cfg" --progress --no-psnr --output "" "") only difference is the M4G-V3 matrix instead the high detail one (couldnt find it)
and just the videofile itself (again dr.no, 105 mins) is even higher than before with morte66's settings, its 1,72 GB. is that somehow comparable to your outcome of comparable files ? seems rather high to me.

how does constant quality work at all, or better said why does/should it give a better quality than normal 2 pass with lets say HQ-slowest options ? is the bitrate determined by the highets frame in the file and therefore used for all other frames ? if not, isnt the system of 2 pass with variable adjusting (high motion pictures get more, no action (or such) pictures get lower bitrates).
if constant quality is really better quality wise, I'd like to keep it, but I want to know if theres a way to estimate the outcoming file size (of the video stream). I'd like to stick to the max number of 1.46 GB for a 2 cd file (=730 mb for one), so that you could actually burn 3x2 cd movies onto one dvd-r (which is what i need to do all the time). but it seems hard to have control about that in constant quality mode with its -crf options, where its said the filesize should have about XX outpute size, but when I test it myself its like 500 MB more. quite unpredictable.

btw.another minor problem, seems like I cant get a proper fourCC info with x264. I chose that in x264 config of MeGUI and also typed that at the video options in the muxer (mkvtoolnix), but when I open the file with virtualdub(mod) I get (apart from quiete some error message about the video stream) a unknown fourCC message, it says just yyyy (uncomressed rb80) or something like that. actually as long as it does not harm the quality of the video its not that bad, but I just like to know why thats happening >_>

[foxyshadis]

Const. Quality won't give a better quality than two pass, but at exactly the same bitrate it'll be approximately the same quality. (With minor differences like direct auto.) But it's faster and it guarantees a certain quality; if you guess wrong in 2-pass you have to re-encode. If you must have it fit a certain size, though, then you'd use 2-pass instead. btw, megui will let you calculate fractions of a DVD, so you can use the bitrate calculator with that instead.

VDubMod requires specific hacks to be made to the file in order to parse it, which make editing problematic, among other things; MeGUI won't supply the hacks.

[Thunderbolt8]

if you guess wrong in 2-pass you have to re-encode.
what exactly do you mean with that, mean I guess the entered bitrate wrong = too low ?
or do you mean other options, in that case I just stick to the hq-slowest profile, maybe with only differences to lower the reference frames to 8 and use a custom matrix.