Which Megui x264 profile would suit my needs?

I've been using the "insane" profile for the last couple of weeks. I've been very satisfied with the quality, but it takes an unbelievable amount of time for me to do a full length movie. Could someone that's been playing around with the profiles for longer reccomend a profile that could give me excellent quality but with a substantially less encoding time. It takes like 15 hours for me to do a movie with Insane.

Here is an idea - try out the different profiles for yourself and arrive at your own decision. It is impossible to give a definite answer to questions like these because "excellent quality" is subjective and also there are many variables here (length of the movie, type of the material, resolution, audio,..blah blah). Oh, and remember - quality always takes time. The vice versa is not always true.

yeah I know, I should try different profiles. I like to hear what other people think though despite the fact that quality is subjective. I just thought maybe there was profile that everyone used which balanced speed and quality. I'll try out slower and see what I come up with.

hi, MaxPlanck - A big part of doing a good encode is making sure you allocate enough bitrate to contain the complexity of the source (kind of what unskinnyboy was saying). If you don't allocate enough bitrate for the particular source, it does not matter what profile you use. One way to bring yourself up to speed on that subject is to do a few test encodes using the CQ-ASP_Q2_eq(crf) profile. It uses a preset crf of 18. You will need to do the test so as to be able to see the command window after the encode is finished (add a "pause" to the end of the batchfile perhaps). Note the last line: "encoded xxxxx frames, 11.12 fps, 1617.83 kb/s" Not an exact science of course, but generally you will want to check that you allocated at least that amount of bitrate for your 2 pass encode if you want an rough approximate quality to crf 18. You might want to play around with changing the crf value up to to 22 to get a smaller encode if that is important to you. The quality will go down some, but it may work for you. You can shorten that test encode to just a few minutes by adding a temporary "SelectRangeEvery(600,12)" at the end of your script. This is a quick, though not exact method to get a general idea of where you need to be, bitrate wise, to deal with the complexity of the source. To give you an example how complexity effects the bitrate needed, here is a snip of data from a data sheet I am working on at the moment. Btw, src3 is Matrix1 which is fairly easy to compress, and src4 is SPR which is very, very difficult to compress. Code:

I do want to hit an exact file size if I can, but truthfully quality is more important to me. I'll try out your reccomendations and see what I come up with, thanks.

I've found that if you are resizing, the end resolution of your file combined with the average bitrate of your 2-pass encoding are really what most determine your quality. In other words, if you set a 720x368 resolution size, a 700MB with a 2-pass x264 encode that will average a bitrate under 1000kbps, you will see quality issues. However, if you do an encode at about 640x352 resolution size, a 700MB with a 2-pass x264 encode that will average a bitrate about 1200kbps, you will end up pretty happy. I've found that these factors (resolution and file size) matter MORE than the high-specific settings (such as b-frames, RDO, etc). Your bitrate MUST be high enough on average or you will not get a good quality. I have found that for great quality with x264 on [640-720]x[320-480] resolutions, you need at least about 1100kbps. But thats just me.

Dayvon, while it may seem so to you, you can't generalize about bitrate as every source has a unique requirement. The reason you may feel what you said is correct is more a matter of most commercial dvd's tend to fall within a similar complexity range by the nature of their production. The confusion arises because their complexity range accidentally or coincidentally tends to fit within many of the bogus, generalized, and incorrect bitrate statements made by some. This is the reason this complete myth keeps propagating itself and causes so much confusion for people newer to encoding. Add: Note the chart above and see how src 1,2,3 could comfortably fall inside your assumption thereby maintaining the myth, while source 4 is completely outside the envelope you mentioned.

You are right DDogg. I definitely won't fight with you on your points. However, what I stated was what I use as a general rule of thumb for a lower limit. I agree that for true quality encoding, your methods do work quite well. When you focus more on reasonable size as opposed to source-matching quality, though, it kinda throws the facts out the window. I tend to like my x264 files at around 1GB on my hard drive. So there is no way that I would encode SPR, a 3 hour movie, at 2,800kbps, which would equate to a 3.7GB file. I'm picky about quality, but not tooo picky. I figured I'd throw a quick bone in about my general experienc for reasonable quality encodes on average retail DVDs. Your scientific way of accuracy has me beat and it is the best way, but for some of us (like me) I just don't care enough to go that far.

ddogg, I'm glad you showed me an example for SPR because that happens to be the very movie that I'm doing next.

Dayvon, sorry for what may have seemed a semi-rant. Was not really targeted at you as it may have appeared, more the frustrating myth. SPR is unusual anyway. It is an interesting exercise though. To be more constructive, I wondered what would be a workable solution for your spec of ~ 1g filesize for SPR. Ran 2 samples of SPR with a lowered resolution of 480 X 256 unfiltered: crf 18 - 38,704,750 crf 18.1 - 38,212,804 Look at the attached tool sheet where these numbers have already been input - note that Q22.0.mp4 is not too far off.[] Then, 2 more sets using filters were run. This is a touchy area when encoding SPR because altering the grain alters the directors original artistic idea. Still, for discussion purposes only, input these numbers into the tool sheet and note the bitrate changes: crf 18 - 36,644,857 - RemoveGrain(mode=2) crf 18.1 - 36,163,617 - RemoveGrain(mode=2) Then this heavier filter: crf 18 - 32,986,779 - FFT3DFilter(sigma=3) crf 18.1 - 32,597,084 - FFT3DFilter(sigma=3) Note that Q20 now shows a bitrate of 1,023 and a predicted size of 1,300,429,254. Actual size would be at 5-15% smaller. Not too far off your spec.