--me tesa

[Dark Shikari]

--me tesa (http://trac.videolan.org/x264/changeset/728)

Have fun.

/thanks, pengvado, for optimizing this heavily and putting it in SVN :)

[coolphoenix]

i'm sorry, but i can't find any info on tesa with forum's search, what kind of motion search algorithm is it? some infos anywhere?

[froggy1]

i'm sorry, but i can't find any info on tesa with forum's search, what kind of motion search algorithm is it? some infos anywhere?

Hadamard SATD

[check]

See this graph: http://akuvian.org/images/tesa2.png
The data points are various --merange settings from 4 to 64.

[coolphoenix]

See this graph: http://akuvian.org/images/tesa2.png
The data points are various --merange settings from 4 to 64.

alright, thanks, looks really promising.

[Sagekilla]

Am I reading this right, the version number jumped by 14 in less than 8 hours?! Also, nice work. Look forward to trying this out, but is there any chance we could get one on your AQ-ified builds?

[Inventive Software]

Yep, akupenguin went on a coding spree! :D

Good to see this in the SVN. Now I gotta compare it to "ordinary" ESA. :D

[TheRyuu]

Slighty off topic, but is me-prepass ever going to make it into the svn? (or will we see an updated patch for it?)

Thanks.

[Zanejin]

check, could you list the specific --merange settings used?

[bob0r]

Slighty off topic, but is me-prepass ever going to make it into the svn? (or will we see an updated patch for it?)

Thanks.

When its finished, it will be in SVN.

[check]

check, could you list the specific --merange settings used?Should be: 4 8 12 16 24 32 48 64

[TheRyuu]

When its finished, it will be in SVN.

Thanks for the incredible specific answer. :p

In any case, it's nice to see these things moving into the svn.

Thanks :)

[audyovydeo]

is tesa multithreaded ?

cheers
a/v

[Dark Shikari]

is tesa multithreaded ?

cheers
a/vYes .

[Inventive Software]

It had bloody better be... I'm getting 1.7 FPS with a dual-core Turion64 @ 1.6 GHz. I knew it was slower, but didn't know it was that much slower! :p

[cogman]

It had bloody better be... I'm getting 1.7 FPS with a dual-core Turion64 @ 1.6 GHz. I knew it was slower, but didn't know it was that much slower! :p

:) I tried to encode a 24 minute clip last night, 3.1 GHZ Core 2 Duo. But my setting brought me clear down to 0.24 fps. lol I was using a merange of 64, I changed that this morning to 24 as that looks like it is about the most optimum level (according to the chart)

[Inventive Software]

:eek: That's unbelievably slow! Good job I left it as is! (Was yours HD or SD content?)

Settings I used were 8 refs, 7 Bframes, all the B-frame options enabled, subme 5, 8x8dct, all the search options, and CRF 26. This to encode a 52 minute DVD. It's taking about 8 hours roughly. :rolleyes:

[akupenguin]

as that looks like it is about the most optimum level (according to the chart)
Don't rely too much on the chart, it's an average. Some individual clips look like this (http://akuvian.org/images/tesa-hsing.png) or that (http://akuvian.org/images/tesa-grimmc.png).

[cogman]

Don't rely too much on the chart, it's an average. Some individual clips look like this (http://akuvian.org/images/tesa-hsing.png) or that (http://akuvian.org/images/tesa-grimmc.png).

interesting. I would have never guessed that compression would actually get worse with too high a me range (via your second chart) But, 24 still seems like a pretty safe bet (all though, not as safe as I assumed)

As for my cruel settings (at least my CPU thought they where) merange of 64 (that hurts), ref 16, b 16, crf 20. And it was a SD film (no filters applied) Im getting much faster speeds with ref 6, and merange of 24. (about 3.5 fps, as opposed to 0.24 :D)

Really, I just like to see how slow I can make x264 go, thats all. BTW the clip is real life footage and progressive (MASH, early sessions) with a fair amount of noise. the second encode is not done (doing the whole thing) but we will see what it looks like when finished. This is my first encode using some newer options (IE Dark's AQ and tesa)

[Sagittaire]

:eek: That's unbelievably slow! Good job I left it as is! (Was yours HD or SD content?)


Use insane setting is never an obligation (IMO tesa is useless with actual CPU). In theory H264 (or MPEG4 ASP) can virtualy make infinite encoding time (0.0000 .... 00001 fps) if you make all the possible search combinaison.

[Adub]

Super cool!!!

Thanks again pengvado!! I always loved super optimized code, especially when it produces results like this!!!

You rule man!!

[Dark Shikari]

Use insane setting is never an obligation (IMO tesa is useless with actual CPU). In theory H264 (or MPEG4 ASP) can virtualy make infinite encoding time (0.0000 .... 00001 fps) is you make all the possible search combinaison.Agreed... if one has tons of extra CPU time one would probably be better off using some sort of bruteforce B-frame decision (or RDRC).

[Inventive Software]

Is there a way of doing such a thing with the spare GPU power available?

[Dark Shikari]

Is there a way of doing such a thing with the spare GPU power available?CUDA support will eventually be coming; I believe Avail Media is hiring a dedicated developer to port x264's motion search code to 8800 GPUs.

[jethro]

Speaking of slow... can CABAC be optimized by brute-force to find optimal parameters thus gaining a couple of percent in compression?

[Dark Shikari]

Speaking of slow... can CABAC be optimized by brute-force to find optimal parameters thus gaining a couple of percent in compression?No. CABAC only compresses in one way and only decompresses in one way, IIRC. Every single context choice is 100% predictable.

Optimization consists of choosing decisions that minimize CABAC cost--a multi-MB trellis could do that sort of thing framewide, though be very slow.

[jethro]

now that was quick:)
Oh yes I remember now akupenguin saying something about CABAC in snow codec which was more efficient and even compatible but small rounding errors in decoder would make porting it dangerous.

[Inventive Software]

CUDA support will eventually be coming; I believe Avail Media is hiring a dedicated developer to port x264's motion search code to 8800 GPUs.

And there was me thinking I could attempt it as a final year project possibly! :D

[Dark Shikari]

And there was me thinking I could attempt it as a final year project possibly! :DTalk to Dakaz about it :)

[A.Fenderson]

I'm a complete beginner in regards to learning about x264's many options and parameters, so I've been going over the list of settings given here (http://mewiki.project357.com/wiki/X264_Settings), and the explanations of --me esa and tesa (http://mewiki.project357.com/wiki/X264_Settings#me) have me confused. I'm no math expert, but when esa is described as "a highly optimized intelligent search of the entire motion search space within merange of the best predictor. It is mathematically equivalent to the bruteforce method of searching every single motion vector in that area, though faster," I have a pretty good intuitive understanding of what that means. However, tesa's description claims to be "like exhaustive, but a little bit better and a little bit slower," this seems contradictory--if esa is already functionally equivalent to brute-forcing every possible motion vector in the defined area, the only possible improvement would seem to be a more intelligent algorithm which is also functionally equivalent to brute-forcing every possible motion vector but doing so more quickly. The three charts listed above also prove that for certain values of merange, tesa does yield lower bitrates than esa at identical merange values. How is this possible unless esa is not functionally equivalent to brute-force, and therefore is not really examining all possible vectors and choosing the best ones?

interesting. I would have never guessed that compression would actually get worse with too high a me range (via your second chart)

This also intuitively makes no sense to me--why the bitrate increase as you proceed through relatively large values of merange through even larger ones?

[LoRd_MuldeR]

Even if you search the entire search space ("brute force") still the question is: How to define what is the "best" fitting motion vector?

AFAIK usually the sum of absolute differences (SAD) is used as a quality metric for that purpose. With "hadamard transform" the sum of absolute transformed differences (SATD) is used instead.

Anyway, it has to be noted that both, ESA and TESA, are overkill for practical purposes. You won't get any improvement over UMH or the improvement is negligible/unnoticeable.

[A.Fenderson]

Ah, thank you. I hadn't realized different metrics were being used for determining the best vector in each algo. I know these options are both generally considered overkill, but I'm trying to understand all options at least to a depth where I can feel confident in deciding which to try and which to leave alone.

As for the bitrate increase for very large values of merange, any thoughts on what might cause this?

[LoRd_MuldeR]

As for the bitrate increase for very large values of merange, any thoughts on what might cause this?

Bitrate increase at what? Same CRF value? Same perceived quality? :confused:

(And again it has the be noted that everything above Me-Range 16 is overkill. No x264 preset uses more than 24, not even "placebo". Everything up to and including "slower" uses 16, the default)

[A.Fenderson]

Good questions--there doesn't seem to be much information about any of the other settings/methodology used in those comparisons linked above, but whereas the first one (http://akuvian.org/images/tesa2.png) (the average I believe) shows a diminishing-returns type of plateau for all me types, and the second one (http://akuvian.org/images/tesa-hsing.png) shows anywhere from quasi-linear compression gains to plateauing similar to the first/average graph, the third graph (http://akuvian.org/images/tesa-grimmc.png)(/clip) shows worse compression efficiencies for all variable-range me types on the high end of the range (24 to 64). Assuming all other settings were the same across all tests, what properties of this clip might cause lower compression efficiencies for all types of me (including UMH) whenever increasingly large search areas are used to find "better" motion vectors?

If we were to assume that crf was used and identical across all tests, then what might account for this compression percentage degradation? Might the motion vectors the algo chooses which end up being on the periphery of its search radius take more data to encode than would smaller (yet slightly less accurate) motion vectors?

[LoRd_MuldeR]

If we were to assume that crf was used and identical across all tests, then what might account for this compression percentage degradation? Might the motion vectors the algo chooses which end up being on the periphery of its search radius take more data to encode than would smaller (yet slightly less accurate) motion vectors?

As has been explained a million times, CRF is not a constant quality mode. The same CRF value will only give "similar" quality for different sources. And only as long as you don't change any other options. As soon as you change other options, the CRF values change their meaning (more or less) and thus aren't comparable anymore! That's why you cannot compare different settings in CRF mode. You must either compare files of identical file size (then you can judge the quality) or you must compare files of the same perceived quality (then you can compare file size). The latter is hard to achieve, of course. So if you want to compare different Me-Range values, you should create files with different Me-Range setting, but identical file size. Use 2-Pass mode for that purpose. Then compare them quality-wise...

[infoeater]

Settings:
program --preset placebo --tune ssim --crf 18.0 --thread-input --threads 1 --keyint infinite --min-keyint 1 --psnr --ssim --merange X --output "output" "input"

X as label, xy point chart, bitrate and SSIM dB:

http://img59.imageshack.us/img59/4608/ssimbitrate.png

Looks like --merange 9 is much better than --merange 64 for this particular 768x432@60 clip.

So again, how it's possible? Is it extra cost for encoding longer motion vectors, or more motion vectors directing to different object, but with similar random noise (which is bad decision because noise will not be the same in the future)?

[burfadel]

What x264 version were you using? so in that clip, only 65, 63, and 32 produced 'better' (in terms of SSIM) results?...

[infoeater]

What x264 version were you using?
I used "x264 r2074 2641b9e". Last version used by MeGUI.

so in that clip, only 65, 63, and 32 produced 'better' (in terms of SSIM) results?...
Yes, however with higher bitrate.

[LoRd_MuldeR]

Yes, however with higher bitrate.

Comparing SSIM values of encodes with differing average bitrate is pointless...

If, for example, one encode has a better SSIM compared to another encode, but at the cost of a higher average bitrate, then the only conclusion is that no conclusion can be drawn ;)

Improving the quality by increasing the bitrate can always be done. You don't need to touch any other settings, such as "--merange", for this!

What would be of interest is: Increasing the quality at the same bitrate -or- decreasing the bitrate at the same level of quality. In other words: Actually improving the compression.

But if both, the quality (e.g. SSIM) and the average bitrate (i.e. file size), have changed at the same time, then it's pretty much impossible to draw any conclusions...


That's why you can't make such tests with CRF mode and a constant CRF value! You either have to tune the CRF value for each encode to get identical visual quality (in which case you can compare the resulting bitrates) or you have to tune the bitrate of each encode to get identical output file size (in which case you can compare the resulting quality - via SSIM or even better subjectively). The latter test can be done more easily, thanks to 2-Pass mode.

(And no, using the identical CRF value for different encoders does not yield identical output quality. Especially not when changing other influential encoder settings)

[infoeater]

ok, but if one encode have higher quality and lower bitrate than another it is better. So (in this particular sample) encode with --merange 9 is better than encodes with --merange X 7, 8, 15, 16, 17, 31, 33, 35 and 64.

--merange 9 is much better than --merange 64 for this particular 768x432@60 clip. It offers both lower bitrate and higher quality. We can't compare it with --merange 65, 63 and 32, because their offer higher quality, but at the cost of higher bitrate.

[LoRd_MuldeR]

--merange 9 is much better than --merange 64 for this particular 768x432@60 clip. It offers both lower bitrate and higher quality. We can't compare it with --merange 65, 63 and 32, because their offer higher quality, but at the cost of higher bitrate.

I think, that's right. However, as you said, it's only the result for one specific clip (what was the length?), so this might just have happened "by chance".

In order to generalize your conclusion, the test would need to be re-done with a complete "test set" of various clips.

Also keep in mind that SSIM and "perceived quality" still are two different things.

Whether the different "--merange" values actually result in a perceivable difference (at a reasonable bitrate), that is a different question, I think...

[infoeater]

My clip was very short - 688 frames. I am not generalizing here. In fact I would expect longer clips to show more clear pattern (however different for each clip) - with peak of quality at some merange. I don't think, that --merange 9 will be optimal even for this type of clips.

It just think, that larger --merange could give worse results sometimes. And I am interested why? And maybe if there is theoretical explanation it will be solution to this problem, with benefit to all meranges. For example if longer vectors require more bitrate to encode maybe it will be beneficial to weight it in selecting right vector. If the reason is similarity in noise maybe it will beneficial to use denoised source to estimate motion vectors or check how picking motion vector will affect future frames in -veryslow and -placebo presets (there are many ways to do it different way than brutal force)?

Generally in may be possible to find better motion vectors, than ones linking to most similar content.

[Dark Shikari]

For example if longer vectors require more bitrate to encode maybe it will be beneficial to weight it in selecting right vector.Any remotely decent encoder (x264 included) already does this. --merange is not directly related to any maximum motion vector range, so the point is moot, however.

[infoeater]

Why higher --merange sometimes decrease quality and increase bitrate at the same time?

[Dark Shikari]

Extremely high merange (e.g. >64) is unlikely to find any new motion vectors that are useful, so it may very slightly decrease compression in some cases by picking motion vector deltas so large that they worsen prediction of future motion vectors in the rare cases they're locally useful, making them worse than useless.

The effect is so small as to be near-negligible, though, and you shouldn't be using such insane settings.

[infoeater]

Thank You!

Am I correct now, that x264 estimate motion vector, and then search near this estimated motion vector up to the distance from --merange?

And how it is possible, that high --merange hurts lossless compression too?

[LoRd_MuldeR]

As far as I understood, the motion vector for the current frame is predicted from the previous motion vector(s).

Thus x264 will start its search at the predicted motion vector. The final decision is then stored as the delta (offset) between the predicted motion vector and the selected motion vector.

And, as "good" motion vectors are usually found close to the predicted one (not very far away from there), using extremely high search ranges generally doesn't help much.

Also, in the rare case, where using a very high search range actually finds a better motion vector, that "far away" motion vector may actually worsen the prediction of future frames...

[infoeater]

Probably it is mostly as you said (you have the gift of clear explication). I will add only that Dark Shikari said:

Any remotely decent encoder (x264 included) already does this. --merange is not directly related to any maximum motion vector range, so the point is moot, however.

What may mean that vectors are stored, not deltas. However after compression effect may be the same - larger delta - more bits. Larger deltas may also allow statistically larger vectors.

In lossless compression chosen vector should not allow actual content to change, so larger future vectors are only explanation (as codec take into account only cost of encoding current large vector, which latter will have to be neutralized with additional cost).

Everything I said here is speculation, as actually I don't know anything else that large vectors sometimes hurt compression (it is nice that this has finally been said as it may benefit others).

I will love to read some text in Internet, which will explain the whole x264/H264 with links to clear longer explanation for each part. I understand that satisfying my curiosity could cost x264 development or solving some real problems however.
Collection of links with short description to something simpler than x264 source or H264 standard will be very nice as well.