need an advice with CRF encoding

[ggab]

i will encode video at 640x480 30fps, for PC playback (because, if not, i need maximum 3 bframes...)

is this custom command line (from MeGUI) right?

--crf 24 --level 3.1 --keyint 300 --min-keyint 30 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 7 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"


i also have 640x480 15fps 320x240 20fps

so, i need only change --keyint 150 --min-keyint 15 - and 200/20, right?

du u think is it a great encode? (non anime material)

thanks

EDIT:
here it is a short sample from the ORIGINAL:
http://www.wikifortio.com/571397/eMVI_2699.avi

[ggab]

i'm using latest Megui with x264's 736-2 Jarod patched

this build include: Variance AQ 0.48 from Dark Shikari?

with default to --aq-strength 0.5 and --aq-sensitivity 13 ??

quote from http://avidemux.org/admWiki/index.php?title=H264
Adaptive Quantization (AQ)
AQ Strength: This setting controls the amount of AQ that is applied to the frames. The default AQ Strength is 0.5 now, so AQ will be enabled by default. The default value should be well-balanced and give good AQ results for most sources. If you think your video requires stronger AQ, then you can raise the AQ Strength. A value of 1.0 should give "medium" AQ. You can go even higher, if necessary. Setting AQ Strength to 0.0 will disabled AQ, like x264 worked before AQ was added.
AQ Sensitivity: This setting controls the "center" of the AQ curve. A value of 10 will raise most QPs, a value of 20 is a good general-purpose sensitivity and a value of 30 will lower most QPs. A value of 0 will use Automatic Sensitivity, which avoids moving bits between frames. The default value is 13 now, which is supposed to not alter the average bitrate in CRF mode (compared to AQ disabled). Usually you won't need to change the AQ Sensitivity setting!
Remarks: The purpose of Adaptive Quantization (AQ) is moving more bits into "flat" macroblocks. This is done by adaptively lowering the quantizers of those blocks. Without AQ, flat and dark areas of the image tend to show ugly blocking or banding. Thanks to the new AQ algorithm, blocking and banding can be greatly reduced! With AQ enabled, you can expect a significant gain in overall image quality. Especially in dark scenes and scenes with "flat" backgrounds (sky, grass, walls, etc.) much more details can be preserved. Furthermore AQ is extremely useful for preserving film grain, even at relatively low bitrates. Nevertheless AQ seems to perform less efficient on Anime material.

another question:
how about if i change b-bias to 10 (from 0) and me-range to 24 (from 16) ? it seems to be better, no?

info from:
B-Frames:
Bias: This setting controls the probability that a B-Frame is used instead of a P-Frame. The default value is 0, which also is the recommended setting. A positive value increases the probability that a B-Frame is set. In contrast a negative value decreases the probability that a B-Frame is set. Of course the encoder will never violate the Max Consecutive limit, no matter what Bias setting is used

Motion Estimation:
Range: This setting defines how many pixels are analyzed for motion estimation. Higher Range values result in a more accurate analysis, but will also slow down the encoding speed. Note that this setting only takes effect if you use the "Multi-Hexagon Seach (UMH)" method or an even higher method! The default value is 16, which should be sufficient for most videos. Nevertheless "high motion" videos and HD material benefit from higher Range settings. A value of 24 seems to be a good compromise.


and from http://trac.handbrake.fr/wiki/x264Options
Motion Estimation Range (me-range):
This range is the radius, in pixels, x264 should use for motion estimation searches. It only has an effect when you use Uneven Multi-Hexagonal or Exhaustive searching. 24, 32, and 64 are good values.

[LoRd_MuldeR]

1. Yes, default AQ settings are "--aq-strength 0.5" and "--aq-sensitivity 13" with usually no need to change them (assuming you are using a build with v0.48 AQ patch)

2. I'd definitely keep b-bias at "0" unless I have a very good reason to change it, because that's the default value the automatic b-frame decision is optimized for.

3. Raising ME Range to 24 (when using UMH, ESA or Hadamard) will give some improvement! Especially on "high motion" material an with "HD" stuff. But it's significant slower than 16...

BTW: You can find up-to-date x264 builds with v0.48 AQ patch at this (http://x264.tk/) place for example.

[Sharktooth]

latest megui already inlcudes a x264 build with VAQ 0.48.

[ggab]

here it is a short sample from the ORIGINAL:
http://www.wikifortio.com/571397/eMVI_2699.avi

in Variance AQ Megathread - Doom9's Forum
I found that:
--aq-strength 0.3 --aq-sensitivity 16.5 is good to very low res samples... <= 640x480 ? but i need to read a few pages more... what do u suggest with VAQ in low resolution movies?

thnks

[Dark Shikari]

here it is a short sample from the ORIGINAL:
http://www.wikifortio.com/571397/eMVI_2699.avi

in Variance AQ Megathread - Doom9's Forum
I found that:
--aq-strength 0.3 --aq-sensitivity 16.5 is good to very low res samples... <= 640x480 ? but i need to read a few pages more... what do u suggest with VAQ in low resolution movies?

thnksLeave it on the defaults. Don't touch it, especially sensitivity, without good reason.

[ggab]

well, i change it to:

--crf 24 --level 3.1 --keyint 300 --min-keyint 30 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 7 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --merange 24 --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"

and i got a 2.343KB file vs 11.542KB Original one.

i need to compare quality... maybe tomorrow :)


PD: i use the default-direct spatial for CRF encode (Sharktooth's suggestion: no temporal, no auto)

any more to add/recommend to the command line?



TIP for trying, in the avs to load with MeGui use:
DirectshowSource("C:\PATH\eMVI_2699.avi")

[LoRd_MuldeR]

1. Do you really need "--filter -2,-1" in your encode ???
2. "--ref 16" looks a bit overkill. Usually 6-8 refs should be far enough, except for Anime stuff maybe
3. Not using "--analyse" at all should be sufficient (defaults)

BTW: I'd only fall back to DirectShowSource() when AVISource()/FFmpegSource() fail...

[ggab]

3. Not using "--analyse" at all should be sufficient (defaults)
it is because MeGUI profile's CQ-ASP_Q2_eq(crf) use them :
--crf 18 --ref 3 --mixed-refs --bframes 16 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"

2. "--ref 16" looks a bit overkill. Usually 6-8 refs should be far enough, except for Anime stuff maybe
yes, i know, but i read that "x264 using more B-Frames won't hurt the quality at all: You can safely choose the maximum of 16 consecutive B-Frames, because x264 will always choose the optimal number of B-Frames. Even if you allow up to 16 consecutive B-Frames, the encoder will seldom go that high. Limiting the number of B-Frames to less than 16 will only restrict the encoder's freedom to choose to optimal number of B-Frames."

1. Do you really need "--filter -2,-1" in your encode ???
Because is in the CRF's Sharktooth profile... i guess it's ok for real (normal) life scene...
And i also read, "If you like a more sharp video and don't mind a few blocks here and there, then you might be happy with -2:-1"

PS: how can i know the CRF number (lower i guess... :confused: ) to use with my encode,
to be as close as possible to the original source's one???

thanks :)

[Dark Shikari]

yes, i know, but i read that "x264 using more B-Frames won't hurt the quality at all: You can safely choose the maximum of 16 consecutive B-Frames, because x264 will always choose the optimal number of B-Frames. Even if you allow up to 16 consecutive B-Frames, the encoder will seldom go that high. Limiting the number of B-Frames to less than 16 will only restrict the encoder's freedom to choose to optimal number of B-Frames."He said reference frames, not B-frames.

[ggab]

yes, i was wrong :o

Max. Ref. frames controls how many frames can be referenced by P- and B-Frames. Higher values will usually result in a more efficient compression, which means better visual quality at same filesize. Unfortunately more reference frames will require more time for encoding and more CPU power for playback. By default the number of reference frames is limited to 1. It's highly recommended to raise the number of references to at least 3. Nevertheless using more than 5 or 6 reference frames for "real life" footage should be avoided, as it won't improve the results any further! At the same time anime and cartoons benefit a lot from additional reference frames. Sometimes even the maximum of 16 reference frames can be helpful for such material.

So, for "real life" scenes, 8 is quite enough ???
and 16 only for anime/cartoon is see...

-> is it real that 16 will require more CPU power for playback???

and.... if i use -ref 8, will i achieve smooth DXVA playback with a compatible GeForce 8000 or ATI HD gfx card?

Settings for SD
--level 3.1 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 25000 --me umh --merange 12 -b-pyramid

Here are some settings for max DBP size

L3.1
720x(any): 8 (--ref 8)
720x576: 11 (--ref 11)
720x480: 13 (--ref 13)

x264 Known Hardware accelleration problems and solutions - Doom9's Forum (http://forum.doom9.org/showthread.php?t=132924)
or if i re-ask that question...
will my encode get the DXVA playback enabled?
or i will need to low the the --merange to 12 for example???

[Dark Shikari]

-> is it real that 16 will require more CPU power for playback???Not by any measurable amount.

[LoRd_MuldeR]

If I'm not wrong, "--merange" will not influence Hardware/DXVA compatibility at all. It will simply control how far x264 will search internally for motion - at encoding time. This shouldn't effect the output bitstream and the playback at all...

Ref frames do have a huge effect on Hardware/DXVA compatibility, because hardware decoders have a limited buffer for reference frames. I think it depends on the resolution and on the buffer size how many reference frames can be handled by a hardware decoder. See this thread:

http://forum.doom9.org/showthread.php?t=132924

[cogman]

24 will give you quite low quality IMO. I like 20-21 some hate anything more then 18. In the end, it comes down to personal preference.

A fairly good measure of quality (besides your eyes) is the SSIM result at the end of the encode. I don't know where you go in Megui to get that (I believe it shows up in the log). 1.0 is a prefect encode and 0.8 is a crap encode. I like to have mine hit around 0.97 and up (unless I'm encoding for an Ipod or something similar)

[wata]

if you use vaq
filesize crf 18 will about equal to crf 20
in other word, if you are using crf 18 before and you use the vaq v0.48 you have to increase crf to 20 now in order to get about the same filesize as before.

[desta]

if you use vaq
filesize crf 18 will about equal to crf 20
in other word, if you are using crf 18 before and you use the vaq v0.48 you have to increase crf to 20 now in order to get about the same filesize as before.
I think you might have worded it wrongly then..?

It seems you're trying to say: crf 18 + no-vaq gives the equivalent filesize to crf 20 + vaq.

[saint-francis]

if you use vaq
filesize crf 18 will about equal to crf 20
in other word, if you are using crf 18 before and you use the vaq v0.48 you have to increase crf to 20 now in order to get about the same filesize as before.

This is not true in my experiences. I have been testing VAQ and CRF extensively and the resulting differences in size is not predictable in any way at all. Yesterday I encoded a movie with CRF 18 which resulted in 2.5 GB with VAQ and 1.2 GB without. The movie I tried before that had a difference of less than 50 MB. At first I also tried comparing CRF 18 with no VAQ to CRF 20 with VAQ and I found that across the board that using CRF 18 and no VAQ always produced a better picture.

[wata]

I think you might have worded it wrongly then..?

It seems you're trying to say: crf 18 + no-vaq gives the equivalent filesize to crf 20 + vaq.

yup, that what i am trying to say
previously i alway encode with crf 18
so when i try vaq with the same video the filesize increase
i have to increase crf to 20 with vaq enable to match the filesize of crf 18 without vaq

but i only test it with about 15 files, mostly clips capture from tv with hauppauge pvr250, 4-5mins each