can you guess how slow x264 is?

[deadrats]

hey guys, anyone up for a little game? as most of you know x264 enjoys a reputation for being a fast encoder, in large part derived by the encoding speed achieved with the ultrafast and superfast presets. but can any of you guess how slow it is when you crank all the settings up?

i took a 4 min 10 sec vc-1 @ 12mb/s, 10920x1080 with 128kb/s 44.1khz 16bit wma v2 audio muxed in a wmv container.

i targeted an mkv container with aac audio, 128kb/s 44.1khz and for video i used x264 configured as follows:

reference frames = 3
b-frames = 3
gop = 250
closed gop
motion search = tesa
search range = 32
high@4.1
min quantizer = 0, max quantizer = 30
debocking filter = -2,-2
direct mode = auto
2 pass vbr
12 mb/s
weighted p = 2
weighted b = 1
partitions = all
chroma m.e. = 1
adjusted b = optimal
sub me = 10
trellis = 2
adaptive quantization = auto (2)
AQ strength = 2
psy-rod/psy-trellis = 1:0
lookahead = 250
qp curve compression = 1
mixed references
mb-tree = on
no fast p-skip
no dct decimate
non-deterministic

as you guys can see this is about as aggressive as you can get with x264 settings, i could have used sub-me = 11 and a search range of 64 but that would slow things down way more and in all honesty these settings are probably the highest quality you can get from x264.

so, here's the game: how long do you guys think it took this system, win 7, i7 3770k @ stock clock, 8 gb dd3 to encode a 4 minute 10 second clip? as i don't want to make it too easy for you guys, i won't give you any choices, i want to see if anyone has a guess that is reasonably close.

btw, this test encode clip will be going into a backup as i want to see how divx's hvec does both quality wise and speed wise when x264 settings are maxed out.



edit: doesn't this forum allow us to insert html tags into our posts? i was trying to add the results in a spoiler format or as really small text, but i can't seem to do it.

[rnb5500]

Just a heads up but video length is somewhat irrelevant, more relevant would be total frames.

But assuming this is normal fps clip of 24p or 30p, I'll guess 35 min.

[deadrats]

the frame rate is 29.97fps and the number of frames are 7570.

as for your guess, you are way, way off.

[johns0]

10 minutes.

[deadrats]

unfortunately you moved in the wrong direction; i'll tell you this, i know from experience that x264 is slow when you mate sub-me = 10 + tesa but even i was shocked how long it took this system to finish the encode.

[jagabo]

There's a 100 fold difference in encoding speed between the Ultrafast and Placebo presets in x264. So what. That flexibility is a good thing as it lets you pick your preferred compromise of speed vs. size vs. quality.

[deadrats]

you seemed to have missed the point, one of x264's claim to fame is it's encoding speed and one of the common minuses attributed to soon to be released h265 encoders is the expectation that even if they offer higher quality the encoding speed will be about 5x slower than x264.

with this in mind i wanted to see how long it would take x264, on a high end system like mine, to encode a sample 1080p clip with all the settings maxed out for maximum visual quality and i think we can both agree that one would be hard pressed to get higher quality out of x264 than these settings.

as i said the test clip was 4 min 10 sec and it took 1 hour 22 minutes 20 seconds to encode it, this is with no filtering like deinterlacing or resizing.

i reran my tests with tmpg video mastering works, hand brake, xmedia recode and media coder and they were all within the same 1 hour 20 minute ballpark when i configured each to produce the same output. i had high hopes for xvid4 psp 5 because it's capable of using the quick sync decoder but alas it barely made a dent.

so the question becomes if once the hvec encoders arrive if we were to configure x264 for absolute highest quality without regard to speed would the hvec encoders still be 5x slower than x264 or would the speed difference be a wash? or dare i say it, the hvec encoders actually be a bit faster.

[LightWeightProducer]

x264 is a quick encoder. QS isn't all it's cracked up to be. Sure it encodes fast, but simplify x264's configuration so that it outputs similar quality to a typical QS based encoding program and it's very fast. Unless you spend big bucks to get proprietary ASIC/FPGA based commercial encoders x264 is about as good as it gets speed / quality wise. From my understanding hvec is designed with multiple processors / lines of execution for encoding / decoding in mind permitting better utilisation of resources where h264 would choke.

[deadrats]

x264 is a quick encoder. QS isn't all it's cracked up to be. Sure it encodes fast, but simplify x264's configuration so that it outputs similar quality to a typical QS based encoding program and it's very fast.

i guess you missed the part where i said QS decoder, not encoder.

[Selur]

a few side notes from me, since it's not any more about guessing encoding times,..

• "2 pass vbr + qp curve compression = 1" is telling the encoder on one end to aim for a fixed average bit rate and on the other hand to aim for constant quantizer encoding -> this doesn't make sense to me
• "AQ strength = 2" also looks like a bad idea
• "min quantizer = 0, max quantizer = 30" -> any reason for this?
• using a faster decoder will only help if the decoding is limiting the encoding speed
• If HEVC encoding will ever be faster than x264 encoding at the same quality level strongly depends on how optimized it is. In theory HEVC has more optimizing head room than H.264, but if that is enough and if HEVC encoders will get that much optimization,.. who knows? Atm. we only have a public reference HEVC encoder which is just slow, even slower than the reference H.264 encoder.

Also these are not max quality setting for x264, max quality would be lossless and even if one would aim for lossy encoding, max quality would still require higher reference count no gop size restriction,...

Cu Selur

[Hoser Rob]

you seemed to have missed the point, one of x264's claim to fame is it's encoding speed...

According to whom? Not anyone I've ever read who knows what they're taking about.

You can use the superfast settings but then you're not going to use any of the advanced h.264 settings, which are the real claim to fame of this codec. You may as well use xvid.

Of course encoding will slow down considerably if you use the advanced parameters. Which other codecs do not have BTW. And if they did their encoding would slow down just as much.

You want faster encoding, buy a faster computer.

[LightWeightProducer]

x264 is a quick encoder. QS isn't all it's cracked up to be. Sure it encodes fast, but simplify x264's configuration so that it outputs similar quality to a typical QS based encoding program and it's very fast.

i guess you missed the part where i said QS decoder, not encoder.

meh. Can't be bothered. Perhaps the mods will realise just how much of a troll the opening post of this thread was and can the whole thing.

[johns0]

It's not a troll thread,sounds like you are trolling.

[LightWeightProducer]

Yeah right. Makes opening emotive statement about x264 'supposedly' being something. Cloaks it in a 'game'. Tells people that its 'shockingly slow'. Ignores advice that the topic has been done to death time and time again. Restates the 'supposedly' claim, again ignoring everything that has gone before. If it looks, moves and sounds like a duck, it's a duck.

[jagabo]

It's not a troll thread

Yes it is. Deadrats picked slow settings and got slow encoding. No surprises there. He hates the x264 developers and takes every chance to denigrate the codec.

[deadrats]

Yes it is. Deadrats picked slow settings and got slow encoding. No surprises there. He hates the x264 developers and takes every chance to denigrate the codec.

i am really surprised to see you write this. i don't hate the x264 developers, i consider Jason to be a pompous, self absorbed douche and i consider x264 to be an over-engineered, over-developed, over-rated pile of monkey spunk, but this holds true of most open source software, such as the linux kernel.

the purpose of this test was two-fold

1) to see how slow x264 was on a high end system when all the settings were maxed out. there are tons of threads posted on here about encoding speed versus quality settings, i figured that someone would find it interesting.

2) to set the ground work for a showdown between x264, vp9 and hvec, when maximum quality settings are chosen.

excuse me for desiring to contribute some content to this site.

[deadrats]

• "2 pass vbr + qp curve compression = 1" is telling the encoder on one end to aim for a fixed average bit rate and on the other hand to aim for constant quantizer encoding -> this doesn't make sense to me
• "AQ strength = 2" also looks like a bad idea
• "min quantizer = 0, max quantizer = 30" -> any reason for this?
• using a faster decoder will only help if the decoding is limiting the encoding speed
• If HEVC encoding will ever be faster than x264 encoding at the same quality level strongly depends on how optimized it is. In theory HEVC has more optimizing head room than H.264, but if that is enough and if HEVC encoders will get that much optimization,.. who knows? Atm. we only have a public reference HEVC encoder which is just slow, even slower than the reference H.264 encoder.

i used qp curve compression = 1 because it my understanding that this sets mb-tree to maximum strength. i used 2 pass vbr because i needed the encoded file to have the same bit rate as the source file so that i could compare the quality of the encoded against the source at the same bit rates.


aq strength = 2 i thought would allow aq to really do it's stuff, what do you recommend.


min/max quantizer - i wanted each frame to be of at least a certain quality, i don't want the quality to fluctuate all over the place.


btw, i wanted to use your software to run a test encode with vp9 but it doesn't seem to work, i get the audio but the video never gets encoded. any ideas?

[Steve(MS)]

i am really surprised to see you write this. i don't hate the x264 developers, i consider Jason to be a pompous, self absorbed douche and i consider x264 to be an over-engineered, over-developed, over-rated pile of monkey spunk, but this holds true of most open source software, such as the linux kernel.

At least you're not holding back.
Not that I want or need to defend x264, personally I would rather not encode at all except for special projects.
I simply copy off to a hard drive to be played on media players.
Even copying to usb2 is faster than encoding... especially high def. stuff.

Really though, it appears you are letting your personal feelings about the dev. interfere/cloud your judgement/bias against x264.

It also appears you have a problem with open source/ freeware....

Hey that's fine, pay your hundreds or thousands, many of us will keep using freeware/ open source and be thankful we have it.
Nothing personal here toward you, in fact I find your remarks very slightly humorous.
That bit about Linux really doesn't affect me either since mostly I use Windows OS's.

BTW, hopefully this new encoder works out fine and it totally free without restrictions for us freeware lovers.

[deadrats]

Really though, it appears you are letting your personal feelings about the dev. interfere/cloud your judgement/bias against x264.

It also appears you have a problem with open source/ freeware....

in what way did i let my feelings cloud anything? i configured x264 with the most aggressive settings for maximum quality and reported the encoding time. how is this trolling?

as for my "problem" with open sourse it's because despite the fact that in general it has a market penetration that's practically non-existent, over the past 20 years or so a quasi-religion seems to have sprouted up around Linus, Stallman and a few others and you now have a group of vapid, fanatical proponents who worship at the alter of open source.

these people remind me of Mets fans, every year the team will win about 10 games in a row and all of a sudden they're planning a ticker tape parade, all while ignoring the 16 games in a row they lost or the fact that they are 5 under .500 with no hope of making the post season.

Jets fans are the same way, as is their fat ass coach, i've never seen anyone brag so much about losing back to back championship games.

[Steve(MS)]

Actually I have to somewhat agree with you concerning Linux distros.
I do wish they would get the basic elements fixed so that one wouldn't have to search for scripts to do
what a dialog settings box should do....those simple adjustments we would take for granted in Windows.

Some Linux followers are overly zealous...and perhaps their devs like the honor too much......

Yet I don't believe in throwing out the baby with the bathwater...no need to be extreme in positions.
I am glad even for those apps/softwares that I wouldn't use, I personally like freeware and open source.
I would hate to have had bought every app/software prog. I am using or used.

Ok, you can continue your assault on x264 now...

[Selur]

btw, i wanted to use your software to run a test encode with vp9 but it doesn't seem to work, i get the audio but the video never gets encoded. any ideas?

Yes, vp9 is a bit borked atm. since the changed some stuff which the latest public version isn't adjusted to. If you tell me the OS you use I can send you a modified version and a link to vp9 builds which should work, but atm. vp9 isn't usable at all since it's just to slow (no optimization at all and the whole thing is single threaded).

i used qp curve compression = 1 because it my understanding that this sets mb-tree to maximum strength.

No clue where you got your info from, but the way you use it you basically disables mb-tree.
Higher qcomp -> weaker mb-tree.
Also when playing with heuristics the extremes should normally be avoided.

i used 2 pass vbr because i needed the encoded file to have the same bit rate as the source file

quality will always be lower unless you use lossless (normally encoding to the same bit rate doesn't make sense)

aq strength = 2 i thought would allow aq to really do it's stuff, what do you recommend.

Strongly depends on the source, aq strength influences the data rate distribution between flat and areas and edges (textured areas).
You are favoring textured areas atm. this might make sense, but normally it doesn't.
-> You have to decide what value makes sense. A value of 2 rare does.

min/max quantizer - i wanted each frame to be of at least a certain quality, i don't want the quality to fluctuate all over the place.

I hope, you are aware that the whole adaptive quantization thing is ment to make sure, that a fixed quantizer is not necessary used for the whole picture? So, normally the quantizer distribution across an image is allowed to change as much as codec prefers. -> I think it's a bad idea to limit the quantizer change, depending on you content and the data rate that is used, x264 might never use any quantizer > X anyway, but I see no reason to restrict the encoder on this end.

to set the ground work for a showdown between x264, vp9 and hvec, when maximum quality settings are chosen.

doesn't make any sense to me atm. if you take speed into the calculation, since:
a. vp9 just got it's bit stream frozen (17th of July) and isn't speed optimized at all and it's only in the experimental branch, so even it's developers wouldn't call it a reference encoder atm.
b. hevc is only available as reference encoder, no speed optimization there also
-> comparing these two against x264 and taking speed into account doesn't make sense at this time.

configured x264 with the most aggressive settings for maximum quality and reported the encoding time.

No you:
a. turned most of the screws in one direction without really knowing what you are doing (you left out a few screws, most related to rate control and quantization, but that's fine )
b. you didn't first report the encoding time, but asked others to guess it
-> don't think that the start of the thread was trolling, trolling started at post #16 for me when you started calling people names.

btw. if you call x264 and the linux kernel "over-engineered, over-developed, over-rated pile of monkey spunk" have you ever read and understood the source code they use? (personally I don't think any of those things of those projects, but I really have worked with both and know my way around c/c++ and some other programming languages,..) Most people do not have a problem with the linux kernel, but more with the different user frontends/distros that use it. It's a bit like complaining about the engine of a car, when you simply don't like it's entirior.

despite the fact that in general it has a market penetration that's practically non-existent

you might want to check your numbers, not only for the desktop market, but also for servers and mobile devices
Btw. I really prefer the Windows 7 user experience above all current linux distros, but I wouldn't want to go back to a windows server for storage or web related stuff; on mobiles I'm not sure if I would prefer android over iOS, but I don't like the Windows Phone look&feel, probably mostly because Win8 is such a pain atm. (hoping this will get better with 8.1).

And finding people that are fanatically about one or the other thing really isn't a feat, without those fanatics in each corner far less would happen.

Cu Selur

[deadrats]

No clue where you got your info from, but the way you use it you basically disables mb-tree.
Higher qcomp -> weaker mb-tree.
Also when playing with heuristics the extremes should normally be avoided.

hmm, for some reason i had it backwards, this probably explains why some people seem to swear by mb-tree and all my tests showed that it sucked balls, time to do more tests.

Yes, vp9 is a bit borked atm. since the changed some stuff which the latest public version isn't adjusted to. If you tell me the OS you use I can send you a modified version and a link to vp9 builds which should work, but atm. vp9 isn't usable at all since it's just to slow (no optimization at all and the whole thing is single threaded).

win 7 64 bit, i would really appreciate a build that works, i really want to see what vp9 brings to the table quality wise.

while i'm at it, what containers can vp9 be muxed into? mp4, mkv, avi, ogm or am i stuck with webm? plus what audio can i use? is it just mp3 or can i use aac?

[Selur]

only container which supports vp9 atm. through Hybrid is mkv
(webm doesn't work since mkvmerge doesn't support muxing vp9 to webm atm.)
Audio: everything that is supported by mkv.
Google is probably aiming for: either webm(vp9, opus) or webm(vp9, vorbis) in the future

On the decoding end, only decoder available atm. (from what I know) is vpxdec and it's only decoding the content to either yv12 or i420, so no direct preview.
So putting vp9 into a container doesn't make any sense atm. since to decode it, you would still need to extract the raw video, convert it to Yv12/i420 and playback that with ffplay or whatever raw video decoder you like.