Fast encoding with x264

[somespirit]

If you want fast speed of x264 then use these settings marked with red rectangle on picture, these settings are about motion estimating and have nothing to do with picture quality and

M.E. algorithm - Hexagon
Subme - 6

these settings are very enough to catch any changes between frames ..................

and I think that XviD encoder is using Subme something about 3 or 4 ....... and XviD catchs all movements in any video

[Selur]

these settings are about motion estimating and have nothing to do with picture quality and

you should read up on how MPEG works and what motion estimation is for because what you write there is just totally wrong.

-> use the presets x264/MeGui offers to get faster encoding only mess with the other settings if you know what you are doing.

[somespirit]

nothing in 1-st post is wrong, these settings in Motion Estimation are for deciding (x264 encoder) what sholud be the next frame - B, P or I depending on how much changes (in motion) we have between neighbour frames .............. so you are wrong not me

[Selur]

But the picture quality depends on the picture decision,...

[Hoser Rob]

nothing in 1-st post is wrong, these settings in Motion Estimation are for deciding (x264 encoder) what sholud be the next frame - B, P or I depending on how much changes (in motion) we have between neighbour frames .............. so you are wrong not me

I agree ... that you don't actually know what you're talking about.

[somespirit]

But the picture quality depends on the picture decision,...

it is absolutly wrong unless you mean that choosing that we will have I frame instead B frame which means getting better picture then your sentence is right


Motion Estimation - in this module of x264 there is nothing about compression so how we will get better video picture using better motion decision - ha ha ha

[Selur]

frame choice influences rate control options.
I wonder if like you stated these settings have no influence at all on quality like you stated, why do I get better image quality (at same target size) when I use higher values for these settings.
But you are probably right, I must be getting old and mixing stuff up and starting to hallucinate.

Cu Selur

[jagabo]

This post lists the setting used by the the presets:

https://forum.videohelp.com/threads/349386-Target-bitrate-for-720p-%28From-Blu-ray-sour...=1#post2188503

They may have changed a bit since then.

and I think that XviD encoder is using Subme something about 3 or 4 .......

Xvid only does sub pixel motion estimation when Quarter Pixel is enabled.

[poisondeathray]

If you want fast speed of x264 then use these settings marked with red rectangle on picture, these settings are about motion estimating and have nothing to do with picture quality and

M.E. algorithm - Hexagon
Subme - 6

these settings are very enough to catch any changes between frames ..................

Wrong

They influence the residual, what is stored in a b-frame or p-frame . In general higher settings will yield higher quality at a given bitrate, but at the expense of slower processing

Those settings might be "enough" for some situations but it's a balancing act or tradeoff. There are diminshing returns once you use higher settings

[poisondeathray]

Motion Estimation - in this module of x264 there is nothing about compression so how we will get better video picture using better motion decision - ha ha ha

This absolutely has to do with "better video picture"

p and b frames store the difference between the original and what is predicted. When you have better prediction algorithms (better motion vectors, search algorithms), there is less difference , and less residual is stored, thus smaller filesizes . This indicates better compression, or better quality at the same filesize . Lower quality search algorithm, or subpixel motion estimation method might miss some vector that would have been caught with a more comprehensive search algorithm, thus lower quality search algorithm will decreasing encoding efficiency. Similar for merange - for high action content, movement that exceeds that maximum range will decrease encoding efficiency compared to a range that would have caught that movement. RD models are required because the file size "cost" of motion vectors becomes high - there is a point where the cost is larger than the benefit unless you use RD optimization. Although p and b frame quality are directly affected by these settings, even I frames are indirectly affected, because at given bitrate, there is less to allocate. In the end, it's a tradeoff, because some of the "crazy" settings like placebo might make a 0.00001% difference but take 10x longer to encode

But to say that these settings do not affect quality is absolutely wrong. These differences (between high and low settings) are visible to normal eye , but differences between say something like subme 6 and subme 7 cannot be normally detected unless you use metrics

The bottom line with compression vs speed is there are tradeoffs to be made

[somespirit]

пичове да вземете да се стегнете, ако си мислите че една кокошка ще чока от една пита със семки и няма да вижда всички семки сте леко изкукали, може би ще чока през една семка според вас и като го напънете с subme 11 ще чока във всяка една.........B фреймовете все така добре се определя къде има части от предните B фреймове за да се взема от там готови вече части

и е достатъчен дори и само алгоритъма Diamond Search ......

[Cornucopia]

Ha, ha, ha......WHAT?!! We don't speak Bulgarian, etc. on this site.

Face it, somespirit, you're in over your head and are up against those much more knowledgeable than you, as has already been evidenced by the thread examples.

Scott

[somespirit]

I made 2 tests on video long 05 min 37 sec, so lets see the results (ha ha ha):

test 1 - Diamond, subme 6
-[NoImage] x264 [info]: frame I:91 Avg QP:18.78 size: 26338
-[NoImage] x264 [info]: frame P:1757 Avg QP:21.10 size: 9855
-[NoImage] x264 [info]: frame B:6254 Avg QP:23.13 size: 5122
-[NoImage] x264 [info]: consecutive B-frames: 2.1% 1.8% 6.4% 30.0% 25.1% 19.5% 6.0% 4.7% 2.1% 2.3%
-[NoImage] encoded 8102 frames, 91.58 fps, 1225.01 kb/s

test 2 - Multi hex, subme 10
-[NoImage] x264 [info]: frame I:91 Avg QP:19.56 size: 26327
-[NoImage] x264 [info]: frame P:1757 Avg QP:22.06 size: 10231
-[NoImage] x264 [info]: frame B:6254 Avg QP:25.51 size: 4999
-[NoImage] x264 [info]: consecutive B-frames: 2.1% 1.8% 6.4% 30.0% 25.1% 19.5% 6.0% 4.7% 2.1% 2.3%
-[NoImage] encoded 8102 frames, 41.32 fps, 1222.45 kb/s


all settings are equal in both tests except M.E. Algorithm and Subme

and how we see test 1 have better Avg QP - very strange results, don't even look at the speed of encoding, you have very fast machines and you can wait your Subme to arrive like slow motion turtle ......

[poisondeathray]

I made 2 tests on video long 05 min 37 sec, so lets see the results (ha ha ha):

test 1 - Diamond, subme 6
-[NoImage] x264 [info]: frame I:91 Avg QP:18.78 size: 26338
-[NoImage] x264 [info]: frame P:1757 Avg QP:21.10 size: 9855
-[NoImage] x264 [info]: frame B:6254 Avg QP:23.13 size: 5122
-[NoImage] x264 [info]: consecutive B-frames: 2.1% 1.8% 6.4% 30.0% 25.1% 19.5% 6.0% 4.7% 2.1% 2.3%
-[NoImage] encoded 8102 frames, 91.58 fps, 1225.01 kb/s

test 2 - Multi hex, subme 10
-[NoImage] x264 [info]: frame I:91 Avg QP:19.56 size: 26327
-[NoImage] x264 [info]: frame P:1757 Avg QP:22.06 size: 10231
-[NoImage] x264 [info]: frame B:6254 Avg QP:25.51 size: 4999
-[NoImage] x264 [info]: consecutive B-frames: 2.1% 1.8% 6.4% 30.0% 25.1% 19.5% 6.0% 4.7% 2.1% 2.3%
-[NoImage] encoded 8102 frames, 41.32 fps, 1222.45 kb/s


all settings are equal in both tests except M.E. Algorithm and Subme

and how we see test 1 have better Avg QP - very strange results, don't even look at the speed of encoding, you have very fast machines and you can wait your Subme to arrive like slow motion turtle ......

Why do you think this is strange ?

[jagabo]

Wow, so you've "discovered" that going above the medium preset in x264 can take much longer to encode and may only deliver minimal improvements in picture quality (bitrate mode) or reduction in file size (CRF mode). Incredible.

[somespirit]

последните двама потребителя (двата последни поста) с маймунско мислене ли са ............ или са кухи тъпаци

[Baldrick]

Jag kan också skriva på mitt eget språk. Men ingen förstår vad jag skriver nu.

[DarrellS]

I don't have a clue what you guys are saying but when I use the x264 CLI in Virtualdub, if I'm encoding a lower quality file from the internet, I usually use the superfast setting at crf 24-26. The output file looks as good as the input file (not great but OK). If I'm encoding a good file then I'll use medium at crf 20-21. I don't think you can get much better quality than that and just get a lot of overhead. It's fun encoding the lower quality files in a couple of minutes with a fast processor. Much more fun than encoding a small 320x240 (insert old encoder here) file in six or eight hours on an old Celeron.

[somespirit]

Why do you think this is strange ?

i will answer your stupid question :

answer:

because test 1 which is with Diamond and Subme 6 gives better picture quality than test 2 which is with Multi Hex and Subme 10 that reports statistics of x264 at end of two encodings (look at Avg QP), am i clear or what - да не си завършил килийното училище

[Selur]

btw. if you want to compare the effect of motion estimation and other settings make sure you:
a. encode with a constant quantizer
or
b. encoder with 2pass and aim for the same file size
also average quantizer is not a quality measurement unless you keep all other variables fixed.

crf is not usable to compare other features, since depending on the other features the stuff crf does changes. (remember: crf = constant rate factor)

Cu Selur

Ps.: If you can't stick to the forum language it would be nice if you could switch to another forum, where your preferred language is the forum language.

[poisondeathray]

Why do you think this is strange ?

i will answer your stupid question :

answer:

because test 1 which is with Diamond and Subme 6 gives better picture quality than test 2 which is with Multi Hex and Subme 10 that reports statistics of x264 at end of two encodings (look at Avg QP), am i clear or what - да не си завършил килийното училище

Not so clear... Why don't you post some examples of "better picture quality" ?

Do you understand what Avg QP is ?

You made some claims regarding effects of certain settings on quality, but you didn't even provide any measures of picture quality !! You showed a bunch of numbers and you don't even understand what they mean

You have to add a measure of quality, something like SSIM, PSNR or your eyes . (But SSIM and PSNR are basically less valid if you use x264 psy opts, there are tuning presets for SSIM, PSNR, but visually they do not necessarily correlate well with perception of "quality")

Here is an analogy: I want to see how fast car x vs. car y goes in a 1/4 mile race. I measure car x gets 10MPG, car y gets 11MPG. Which one is faster ? But you didn't even measure speed or time .... Do you see the problem ?

Avg QP has limited meaning without context. If avg qp is the lower, it doesn't necessarily indicate anything about quality . Sure, it's positively correlated - in general lower avg qp's lead to higher bitrates, - BUT you can have lower avg qp AND lower quality, OR lower avg qp AND higher quality. A higher quality encode will have better quality at the same bitrate - so even if avg qp's are similar, the higher quality encode is more compressed and will have higher average quality . I can show you clear visual proof , many examples if you want, it's easy to demonstrate

Also - you post 1 example and you think it applies and is representative in ALL situations, all types of materials, all bitrate ranges ??

[jagabo]

I see far smaller differences in average QP when encoding "--me=umh --subme=8" vs. "--me=hex --subme=6". In fact the reported values are often identical. In any case, I wouldn't take average QP to be the sole arbiter of image quality. I actually look at the resulting videos using an AviSynth script to interleave them with the source so I can easily switch back and forth between the same frame in each video (using VirtualDub), all while using a screen magnifier. For example, this script:

v1=WhateverSource("original.ext")
v2=WhateverSource("encoded1.ext")
v3=WhateverSource("encoded2.ext")
Interleave(v1,v2,v3,v1)

In my experience "--me=umh --subme=8" delivers better overall fidelity. Though admittedly, the difference is small and I probably wouldn't notice at normal playback speed. For DVD sources I usually start with preset=slow, CRF=18. If the video is very grainy I add --tune=grain or --aq-strength=1.8 or thereabouts.

[deadrats]

just to add some fuel to the fire, there is something to using "lower" quality settings that result in faster encodes (from an overall quality standpoint) and it can best be explained by this post:

http://www.gromkov.com/faq/conversion/xvid_options.html

specifically the section called 3e. How does Q-Pel work and when should I use it?

[somespirit]

here is my last encode with "--me=dia --subme=4" - http://thepiratebay.se/torrent/8121530/Andrea_-_Neblagodaren_HDTV_720p__x264_AAC-SSN


and the resulting clip have very good picture quality and i get much faster encoding speed without getting any negative impact on picture quality ......so why we have to use "--me=umh --subme=8+" when we can go with "--me=dia --subme=4"

[Cauptain]

here is my last encode with "--me=dia --subme=4" - and the resulting clip have very good picture quality and i get much faster encoding speed without getting any negative impact on picture quality ......so why we have to use "--me=umh --subme=8+" when we can go with "--me=dia --subme=4"

Very good quality??

My eyes, my eyes...

faster encoding speed

Its ok




Claudio

[somespirit]

now i use "--me=dia --subme=2" even can go with "--me=dia --subme=0" and have blueray quality

and what is "-me" Subpixel refinement - people take a look at one frame i see only pixels and none subpixels ha ha ha , this stupid option makes refinement on subpixels ha ha ha

[jagabo]

and what is "-me" Subpixel refinement - people take a look at one frame i see only pixels and none subpixels ha ha ha , this stupid option makes refinement on subpixels ha ha ha

No, during slow motions you may get smoother results and less buzzing with subpixel motion. But it requires more bitrate to include that greater precision.

[somespirit]

there is no such thing like subpixel motion because we don't have any subpixels at all

[poisondeathray]

now i use "--me=dia --subme=2" even can go with "--me=dia --subme=0" and have blueray quality

and what is "-me" Subpixel refinement - people take a look at one frame i see only pixels and none subpixels ha ha ha , this stupid option makes refinement on subpixels ha ha ha

there is no such thing like subpixel motion because we don't have any subpixels at all

Subpixel refers to the predictive motion vector : it's interpolating an "inbetween" value, so the difference between predicted and actual is less than if you were a full value away. Recall the residual is the difference between predicted and actual - this residual is what makes up the P and B frames. When you have more accurate motion vector predictions, there is less difference, thus less data needs to be stored in the residual = smaller filesize . This leads to higher efficiency - ie. better quality at the same bitrate. This is why better analysis and prediction helps to higher efficiency encodes. But the motion vector data is more complex and costs more - that's why you need RD optimization models to reduce the size - so this is sort of trade off (trade offs is what video compression is really all about)

Yes, this is all theory, but it translates to reality. Just do some tests, it's easy to see the difference and these are pretty much established facts . The lower the bitrate range relative to content complexity, the larger and more noticable the differences. The higher the bitrates relative to content complexity, the more difficult to see the differences.

e.g. parkjoy, 1280x720, 8Mbps , this is a b-frame in both encodes . If you were to use some setting inbetween - yes you guessed it - it would be in the middle in quality and speed . If you can't see the difference, either something is wrong with your test setup or you need to have your eyes examined .

dia, subme 0


multihex, subme 9

[deadrats]

there is no such thing like subpixel motion because we don't have any subpixels at all

if you bothered to read through the link i provided above with regards to quarter pixel detection you would understand what they mean by "subpixel motion".