CodeBlocks

Saturday 16 March 2013

X264 - Motion Estimation Method- Comparison

Last time we looked at the effects of the various subpixel estimation complexity, today we will be looking at how the motion estimation method(MeM) impacts the filesize(all measured in KB), quality and performance(average FPS) according to CRF18 of x264.

There are a total of 5 methods these are in order of complexity:
  • Diamond(dia) - The most simplest method, checking motion vectors at one pixel up, left, down and right and picking the best candidate, this process repeats until it can't find a better motion vector
  • Hexagon(Hex) - Work similarly like Diamond but consists of a range-2 and 6 surrounding points, more efficient than diamond with little performance impact.
  • Uneven multi-hexagon(Uhm) - While slower than Hex, it is able to avoid missing harder-to-find motion vectors. The Me-Range parameter controls its search radius.
  • Exhaustive(Esa) - An optimised intelligent search of the complete motion vector space within Me-Range. Mathematically equivalent to brute force but faster, but still slower than Uhm.
  • Transformed exhaustive(Tesa) - is an algorithm which attempts to approximate the effect of running a Hadamard transform comparison at each motion vector; like exhaustive.

So now that we are more familiar with MeM lets see how it performs.


Futurama SD


The top graph shows the FileSize(Graph area) in KB as well as the performance(line) of each of the different methods. As you can see the relationship between compression and performance takes a turn for the worst with Esa and Tesa.

The bottom graph represents the difference in percentage for speed and compression compared to the default(medium) setting. Here we can see that with Esa for 29.5% performance reduction we get a measly 2.56% extra compression and Tesa does even worse. Uhm compresses better with a slight performance hit of 6.71% slower. Of course will have to see if this translates into any visual artefacts

Still Frame
Diamond
Hexagon

Uhm

Esa

Tesa





















Even though I can see a VERY slight difference between the different methods, I cannot say that one looks better than the other. 


Smaller Motion Detail
Diamond
Hexagon
Uhm
Esa
Tesa

























Again I can notice a difference between the methods but cannot say which is actually higher quality than the rest.

Reel Steel SD
 


So moving onto live action video, we can see that the same trend repeats it self with esa and tesa performing very poorly when compared to dia, hex and uhm.


Still Frame
Diamond
Hexagon





Uhm
Esa






Tesa









As with Futurama its difficult to tell which is better quality.


Smaller Motion Detail
Diamond
Hexagon

Uhm

Esa
Tesa








  .

 

 







And yet again the frame quality is too consistent to say which is better. Maybe we'll see a bigger deference with HD videos

 

Reel Steel HD 

So looking at HD video we see that esa and tesa performs worse than Uhm and is significantly slower. Hexagon seems like a good default method.


Still Frame 
Diamond
Hexagon
Uhm
Esa
Tesa

 

 

 

 

 

 

 

 

 








Yet again with MeM and with HD I can hardly see any difference let alone which is higher quality   

Smaller Motion Detail
Diamond
Hexagon
Uhm
Esa
Tesa

 



















So yet a again its almost impossible to tell which is which and which is better than the other.

Conclusion

Well as you can see visually there isn`t much of a difference, in terms of compression Uhm did consistently better than hexagon or diamond, and esa, tesa also performed better except at HD videos. Regarding performance Esa and Tesa took a massive performance hit, with Uhm only being slightly slower.

Recommended
Hexagon - Performed consistently close to the others.
Uhm - A slight compression gain at a margin performance loss.


 Navigation

  1. Introduction
  2. Presets
  3. Subme  
  4. Motion estimation method

20 comments:

  1. Thanks for your article, really interesting, however I'm not sure if the difference won't be bigger if you restrict final video bitrate instead of choosing CRF.

    If you can do a compare with a "low" bitrate like 900kbps, we will be sure it doesn't matter much.

    And as it's only "still" images, we can't tell if real user visual experience is impacted in high motion scenes for examples.

    Regards

    ReplyDelete
  2. at very low bitrates like 600 - 900 kbps it becomes much more visible since you need to compress as far as possible to preserve the quality.

    ReplyDelete
  3. Muito Obrigado Bom trabalho cara e bom artigo.

    ReplyDelete
  4. Oh...it's Very nice article...thank you so much!

    ReplyDelete
  5. Merci! Je ne savais pas trop quels paramètres utilisé

    ReplyDelete
  6. Its a great pleasure reading your post.Its full of information I am looking for and I love to post a comment that "The content of your post is awesome" Great work. t-com-haus.de

    ReplyDelete
  7. This comment has been removed by the author.

    ReplyDelete
  8. This comment has been removed by the author.

    ReplyDelete
  9. The content is well-researched and well-written, making it easy to follow and understand. Great job, and keep up the fantastic work in providing such informative and helpful content to your readers! Overall, I was impressed by the quality of this blog post and highly recommend it to anyone interested in working with a web development company in India.

    ReplyDelete
  10. "Your blog post gave a clear and thorough understanding of the subject, and I'm appreciative of the insightful information you shared,"
    SAP Analytics Cloud Training

    ReplyDelete
  11. This comment has been removed by the author.

    ReplyDelete
  12. This comment has been removed by the author.

    ReplyDelete
  13. I have seen this compression method used in runtv online anime watching website, I like it video quality there.

    ReplyDelete
  14. Managed Microsoft azure billing partner services allows you to manage billing, reporting,

    ReplyDelete