Settings for Xvid to x264 (crf 24)

[krusty999]

Hi everyone, I want to convert my videos for XVID to X264 and I have some doubts about it.

1. ¿Wich is good CRF or 2pass?
2. ¿Wich deblocking options for movies and for anime?
3. ¿Is good using custom matrices like MP4 GUY LRM?
4. ¿Is good use filters like REMOVEDIRT?

Can post the settings would you ting work well. The quality I want to achieve is like CRF 24. I don't want exact size, but yes maximum compression.

Thanks.

Sorry for bad english.

[Dark Shikari]

Hi everyone, I want to convert my videos for XVID to X264 and I have some doubts about it.

1. ¿Wich is good CRF or 2pass?
2. ¿Wich deblocking options for movies and for anime?
3. ¿Is good using custom matrices like MP4 GUY LRM?
4. ¿Is good use filters like REMOVEDIRT?

Can post the settings would you ting work well. The quality I want to achieve is like CRF 24. I don't want exact size, but yes maximum compression.

Thanks.

Sorry for bad english.
1. If you want a specific filesize, use twopass. If you want a specific quality, use CRF.

2. Leave the deblocking as it is.

3. Generally not unless you have a very specific purpose in mind, such as trying to preserve grain.

4. Depends if the source is noisy. My personal favorite is MVTools motion compensated FFT3DGPU, which is slow (4-6 FPS on a DVD-resolution source) but very very effective.

Some sample "very high quality" settings:

--bframe 16 --b-pyramid --me umh --subme 7 --ref 6 --mixed-refs --bime --weightb --partitions all --direct auto --8x8dct --no-fast-pskip --crf 25 --trellis 2 --b-rdo

Some sample "high quality" settings:

--bframe 16 --b-pyramid --me umh --subme 6 --ref 3 --mixed-refs --bime --weightb --partitions i8x8,p8x8,i4x4,b8x8 --direct auto --8x8dct --crf 25 --trellis 2 --b-rdo

Some sample "medium quality" settings:

--bframe 16 --b-pyramid --me hex --subme 6 --ref 2 --mixed-refs --bime --weightb --partitions i8x8,p8x8,i4x4,b8x8 --direct auto --8x8dct --crf 25 --trellis 1

Some pretty fast settings:

--bframe 16 --b-pyramid --me hex --subme 5 --bime --weightb --partitions i8x8,p8x8,i4x4,b8x8 --direct auto --8x8dct --crf 25 --trellis 1

[Sagekilla]

1. ¿Wich is good CRF or 2pass?

Both have their advatanges; CRF is good for maintaining a constant quality if you don't care about the final file size, whereas 2-pass is good if you have a target file size to hit.

2. ¿Wich deblocking options for movies and for anime?

This can depend a bit.. It's usually suggested to apply deblocking settings (as well as all others) to your personal preference. If you like sharp looking videos, encode using a negative coefficient (I.e. -2:-1) for deblocking. If you don't mind having it slightly mushy and not as sharp, it's perfectly fine to use regular 0:0 or higher if necessary. Just try not to go more or less then -3 to 3, as that's usually overkill.

3. ¿Is good using custom matrices like MP4 GUY LRM?
Matrices can come in very handy when it comes to retaining detail or grain in a movie, M4G's and Sharktooth's matrices work very good in terms of those two goals.

Can post the settings would you ting work well. The quality I want to achieve is like CRF 24. I don't want exact size, but yes maximum compression.

If you want "maximum compression" within reasonable limits, you can pretty much use the following:

--ref 3 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --weightb --b-rdo --bime --direct auto --filter (CHOOSE YOUR DEBLOCK SETTINGS) --partitions all --8x8dct --subme 7 --me umh

Increase reference frames if using anime oriented material, or if you want to encode slightly faster at the cost of compression, lower subme to 6. But if you're literally looking for "reasonable" maximum compression, those settings would probably do well.

[Atak_Snajpera]

Sorry for bad english.
Don't worry I understand you very well. Let me guess you are Espańol :)

CRF is good if you don't care about file size
use 2pass only if you want to fit your movies on CD or DVD


If you are new in x264 world I recommend RipBot264 for this task. If not use MeGUI instead or AutoMKV

[krusty999]

I Downloaded MEGUI but don't have CQ-Insane profile.

Dark Shikari:
Can you make a profile for MEGUI of you "very high quality" settings:

--bframe 16 --b-pyramid --me umh --subme 7 --ref 6 --mixed-refs --bime --weightb --partitions all --direct auto --8x8dct --no-fast-pskip --crf 25 --trellis 2 --b-rdo

And a Sample of FFT3DGPU options for general movie encoding (from XVID to X264)

And what is hadamard patch do? (can use with MEGUI)?)

And what are these options --aq-strength 0.5 --aq-sensitivity 15?

And is convenient modify the DEAD ZONES?

Thanks very much for the answers to everyone.

Saludos de Argentina.

[Sharktooth]

there is no CQ-Insane... just HQ-Insane...

[Dark Shikari]

I Downloaded MEGUI but don't have CQ-Insane profile.

Dark Shikari:
Can you make a profile for MEGUI of you "very high quality" settings:

--bframe 16 --b-pyramid --me umh --subme 7 --ref 6 --mixed-refs --bime --weightb --partitions all --direct auto --8x8dct --no-fast-pskip --crf 25 --trellis 2 --b-rdo
There are already profiles with similar settings.

And a Sample of FFT3DGPU options for general movie encoding (from XVID to X264)
Well if your source is Xvid, you'll want to deblock it first if its blocky at all. If not, no problem.

For FFT3DGPU, I'd use bt=3,sigma=2 (raise sigma if its not enough), and precision=1.
And what is hadamard patch do? (can use with MEGUI)?)Its a patch that's not part of the main source yet--it will probably be in a few days when I finish all my coding.

And what are these options --aq-strength 0.5 --aq-sensitivity 15?Adaptive quantization gets rid of blockiness in dark areas.

And is convenient modify the DEAD ZONES?Modifying --deadzone is only necessary if you want to retain more film grain.

[LoRd_MuldeR]

It seems you all recommend the maximum of 16 b-frames.
Isn't that a bit overkill? Or is 16 b-frames generally recommended for x264?

[Manao]

You should trust the encoder's decision in how to insert bframes optimally. 16 bframes isn't an overkill - it doesn't slow anything down, it doesn't reduce quality, it just gives the encoder more freedom. 16 references, on the contrary, is an overkill : it improves slightly the quality but with an enormous speed drop.

[LoRd_MuldeR]

You should trust the encoder's decision in how to insert bframes optimally. 16 bframes isn't an overkill - it doesn't slow anything down, it doesn't reduce quality, it just gives the encoder more freedom. 16 references, on the contrary, is an overkill : it improves slightly the quality but with an enormous speed drop.
Thanks for the info :)

[Sagekilla]

Indeed, setting B-frames to 16 will result in an almost zero decrease in encoding speed, or sometimes speed will increase as they can be encoded quicker than a P-Frame can be encoded. Sometimes you get a quality boost, other times not.. But like Manao says, it gives the encoder the leverage to use them if necessary. And if you're wondering about the "speed boost," it's usually very minimal, about 0.02 - 0.07 fps faster in my personal encoding.

[krusty999]

Sharktooth
there is no CQ-Insane... just HQ-Insane...

Can you make one?

Thanks.

[foxyshadis]

Open the profile, change 2-pass to const. quant (or const. quality if you want), save it to a new name, and you have the profile.

[danielkun]

I've used FFT3DGPU with mvtools and works like a charm :) BTW, since you're encoding from xvid, I suggest applying some denoising along with debanding, it has certainly helped me. Also, I found this script helpful (but slow):

http://forum.doom9.org/showthread.php?p=1035907#post1035907


Where I find trouble is in deblocking. I've tried some xvid videos with big blocks that seem like 32x32 or 64x64 pixels, used Deblock_QED with its default parameters and I see little to no change, so I need to tweak those parameters.

I also want to archive HDTV MPEG2 TS files (musical performances, japanese HDTV if that's of any relevance), which have noticeable blocking when having high motion scenes (most of the time), cpu=4 works acceptable but blurs the image a bit too much and Deblock_QED again does little help, so could you post parameters for both scenarios please?

[OvejaNegra]

but 16 b-frames during playback is not an abuse to some CPUs?
i have an old computer (celeron 1.2GHz) and it works fine with 2 b-frames, but if using 16 won't do any damage to playback i think i will use it.
But B-Pyramid REALLY freeze some frames (using the last ffdshow build from x264.nl with deblock off and overlay rendering in MPC).
Is B-Pyramid very usefull?
Out of topic question: why in HDTV 1080 is a non mod 16? Is not bad for the codecs?

And yes, i'm anime encoder and X264 is a dream in crf mode, small videos with vERY good quality. Nice work developers!!

[Manao]

but 16 b-frames during playback is not an abuse to some CPUs?No, it's a myth. Bframes are only slightly more complicated to decode than Pframes, and I'm almost certain the bitrate reduction produced by a proper handling of the fade would more than compensate for the slight complexity increase ( making that part of the video actually easier to decode ).

Bpyramidal aren't more complex than bframes. Such freeze are imho indicative of a decoder/demuxer/player bug.

As for 1080, 1920 * 9 / 16 = 1080, that's the only reason.

Edit : for bpyramidal, some fast decoding option in ffdshow implies enabling the deblocking only on reference frames. That disables deblocking on bframes, but not on breferences ( which are added by bpyramidal ). Deblocking is slow enough to make video without bpyramidal faster to decode. But the only reason for that is that the decoder doesn't do everything it should do.

[XPecto]

does Weighted prediction for B-frames and RD based mode decision for B-frames slow down encoding?

[Sergey A. Sablin]

does Weighted prediction for B-frames and RD based mode decision for B-frames slow down encoding?

yes it is, weighted prediction adds computational complexity, while RD decisions add more deep analyze, which finally yet again more computational complexity.

[Dark Shikari]

yes it is, weighted prediction adds computational complexity, while RD decisions add more deep analyze, which finally yet again more computational complexity.
Weighted prediction is not nearly as CPU-intensive as RD though. Both give considerable benefit, quality-wise.

[OvejaNegra]

Bpyramidal aren't more complex than bframes. Such freeze are imho indicative of a decoder/demuxer/player bug.

As for 1080, 1920 * 9 / 16 = 1080, that's the only reason.

Sorry manao but i don't understand the calculation:
Yes i know that 1920X1080 is a correct 16:9 but 1080 is not mod 16, why that size was choosen? Why not a little bigger or a little smaller but with mod 16?
Thanks
sorry for the english

[foxyshadis]

DTV and MPEG didn't exist back when it was first developed for analog broadcast. They did by the time it was standardized, though, so you'll have to ask SMPTE why they didn't seek to pad 8 more lines. There might be discussion in the minutes for 240M. Presumably it either just wasn't important, or the aspect ratio was more important.

[OvejaNegra]

Thanks for the info:
One last question about this matter:
If i'm goin to encode one of these:
1-Leave it as it is (X264 will do less than it can do???)
2-Add lines or crop (the AR will be a little affected)
3-REsize to a full MOD16 (a little cpu consumming, a little quality lose)
What you recomend?
Sorry for the english
Thanks

[foxyshadis]

Follow the standard, x264 won't penalize you but will if you pad 8 lines of pure black. All compliant playback devices will expect 1080, and some may reject 1088 or 1072, though most probably won't. Unlike padding, cropping won't actually hurt, so that's up to you.

[OvejaNegra]

As i supposed
Thanks
PD: where can i find info about AR in HDTV
(Example: what happends to a 4:3 pic, it's resized or letterboxed)
A link will be enough
Sorry for stay out o topic

[XPecto]

yes it is, weighted prediction adds computational complexity, while RD decisions add more deep analyze, which finally yet again more computational complexity.

Thank you
what about having B-frames as references

[Ranguvar]

Just to put in, using higher deblock values (--filter 2,1), more b-frames, and more reference frames are very beneficial to anime.

Most video is not benefited by more than 5 refs, but anime can be noticably improved to 8 or even 10.

That's because anime has so many repeat frames and low-no motion scenes :)

[Sergey A. Sablin]

Thank you
what about having B-frames as references

it shouldn't reduce performance of encoding. it also doesn't reduce performance of the decoding unless you're disabling deblock on B-slices (which is a dirty hack actually).

[xekon]

4. Depends if the source is noisy. My personal favorite is MVTools motion compensated FFT3DGPU, which is slow (4-6 FPS on a DVD-resolution source) but very very effective.


Is FFT3DGPU still your favorite denoiser, any chance I could see a snipet from an .AVS file of yours. where you are using fft3dgpu motion compensated.

I am currently using FFT3DFilter.dll, here is one of my .avs files:

A = NicAC3Source("E:\AviSynth\job.ac3")
V = FFVideoSource("E:\AviSynth\job.mkv")
AudioDub(V, A)
AlignedSplice(Trim(2833, 16127), Trim(16296, 31296))
AutoCrop(0,2,2,0,0,0,0,30,5,0,0,0)
FFT3DFilter(sigma=3,bw=32,bh=32,ow=16,oh=16,plane=4)
AWarpSharp2(128,4,0,44)
DeHalo_alpha(brightstr=2, ss=2.0)

I am still new to Avisynth. I have just about everything figured out but I am still trying to decide which Denoiser I like best, and with what settings.

I noticed your posts in many places dealing with encoding Anime using Avisynth and X264. So I am very curious to have your latest thoughts/input on the different filters, as this thread and the other ones I was looking at are a couple of years old. http://forum.doom9.org/showthread.php?t=134078