System Specs
Athlon 64 3000+
1GB DDR 3200 RAM
Windows 2000 Streamlined (No IE)
x264 core:94 r1564
Source: MaTo's Shadow of the Beast run 11:56.9, frames 18695-22295. (exactly one minute duration)
Script: x264 "D:\Anime\Shadow 18695-22295.avi" --crf 0 --keyint 300 --ref 15 --no-fast-pskip --mbtree --direct auto --subme 10 --trellis 2 --partitions all --me umh --merange ? --8x8dct --no-dct-decimate --output "E:\S\encoded.mp4"
I thought there should be more raw data available here, for newbie encoders that want to interpret data and choose what functions they want for themselves. (and which tradeoffs are worthwhile)
I also decided to pick this segment of the run because one, there's been discussion on how difficult it is to encode, and two, there's both fast moving and slow moving objects during the scene. I'm testing strictly size vs time, hence the crf=0. Quality will come at a later time.
After merange 160 you really start hitting the point of diminishing returns. Sure, you start getting more efficient scanning (due to the range hitting the bounds of the video resolution, but the benefit is miniscule.
----5/26/2010 Update
Script:x264 "D:\Anime\Shadow 18695-22295.avi" --crf 0 --keyint ? --ref 15 --no-fast-pskip --mbtree --direct auto --subme 10 --trellis 2 --partitions all --me umh --merange 96 --8x8dct --no-dct-decimate --output "E:\shadow\encoded?.mp4"
Size benefit with little to no encoding time hit? Sign me up! Its interesting to note that the benefit starts to trail after about keyint 900...I'm suspecting that that's simply the source material being used, and that its a particular scene that's causing a new keyint to be drawn. So, I'm sure you could raise this value to as high as you could possibly want and see real size benefits with little encode time hit..HOWEVER, the higher this value, the messier it might get seeking to random spots in the movie (or if the decoder's smart, time to seek increases). You don't want to set this value to, say, 3600, and have the viewer try seeking to a spot and potentially having him/her watch up to 60 seconds worth of garbled picture (or wait 5-10 seconds as the player seeks) because he/she missed the keyint point, do you?
Anyway, the general rule I've read on other boards is Keyint=FPS*10..so it would be a max of <10 seconds if they seeked to a point and happened to get garbled picture before they start to see things properly again. (on average, 5 seconds)...I think I could say you could stretch it to FPS*15, squeeze 1/2% of size, and be done with it.
Should also note that some of these, like keyint 800 and 1400, are a lot slower. I think my computer hiccuped during those encodes so the values are off. I don't feel like doing a 2nd test set for these, since you can see the general line of time vs size. (maybe I should make a scatter plot graph?)
----5/27/2010 Update
Script: x264 "D:\Anime\Shadow 18695-22295.avi" --crf 0 --keyint 900 --ref 15 --no-fast-pskip --mbtree --direct auto --subme ? --trellis 2 --partitions all --me umh --merange 64 --8x8dct --no-dct-decimate --output "E:\shadow\encoded subme?.mp4"
This appears to have the largest factor on size so far. As such, subme 1 & 2 are NOT recommended in any scenario. Subme 5 is the best performer here, saving ~30 seconds over the higher subme while still (somehow) being smaller than the rest. But, if you were to pick a higher value, subme 10 would be the best bet with little time loss over 6 & 7, while still being in the same bracket as 8 & 9, also while potentially increasing the quality (if it wasn't lossless) over other subme...but that's for another article.
Note: Looking at the MeWiki I realize the brackets exist because subme 7 & 9 also scan for B frames...since they're nonexistent, you get the same size/encoding time.
----Update: More charts!
Source: x264 "D:\Anime\Shadow 18695-22295.avi" --crf 0 --keyint 900 --me ? --subme 5 --merange 16/64 --ref 8 --trellis 2 --partitions all --8x8dct --no-dct-decimate --mbtree --no-fast-pskip --direct auto --output "E:\shadow\encoded ?.mp4"
DIA/HEX/UMH/ESA/TESA
Comparing vs all the different types of motion sensing. merange had to be lowered to 16 due to dia and hex being capped at that value (for better comparison). Hex is only slightly slower and has better compression, so it should always be used over dia. Esa/Tesa is nearly 4x slower than umh, but even so I've gotten curious because of the total amount of time spent..so in the next charts I started comparing umh vs tesa with ref values.
Source: x264 "D:\Anime\Shadow 18695-22295.avi" --crf 0 --keyint 900 --ref ? --no-fast-pskip --mbtree --direct auto --subme 5 --trellis 2 --partitions all --me umh --merange 64 --8x8dct --no-dct-decimate --output "E:\shadow\encoded ref?.mp4"
Merange 64 UMH
Tesa at merange 16 vs UMH at merange 64 has roughly the same time for encode, yet tesa is smaller..interesting..so I did UMH vs tesa at merange 16 with ref values as well.
Source: x264 "D:\Anime\Shadow 18695-22295.avi" --crf 0 --keyint 900 --me umh –subme 5 --merange 16 --ref ? --trellis 2 --partitions all --8x8dct --no-dct-decimate --mbtree --no-fast-pskip --direct auto --output "E:\shadow\encoded ref?.mp4"
Merange 16 UMH
Source: x264 "D:\Anime\Shadow 18695-22295.avi" --crf 0 --keyint 900 --me tesa --subme 5 --merange 16 --ref ? --trellis 2 --partitions all --8x8dct --no-dct-decimate --mbtree --no-fast-pskip --direct auto --output "E:\shadow\encoded ref?.mp4"
Merange 16 TESA
Even at ref 15 UMH filesize can't go under tesa's size at ref 3..one of the many deciding points for me to switch to tesa.
Source:x264 "D:\Anime\Shadow 18695-22295.avi" --crf 0 --keyint 900 --me tesa --subme ? --ref 5 --merange 16 --trellis 2 --partitions all --8x8dct --no-dct-decimate --mbtree --no-fast-pskip --direct auto --output "E:\shadow\encoded ref55.mp4"
Retest: Subme 5 vs 10 using TESA
Well, subme 5 being a smaller encode was mostly a fluke..since subme 10 is not much slower, I'll stick with that value. Aside from the merange 64 tesa encodes, 16464055 is the smallest file size I've reached (while still being very efficient with encoding)
(Bitrate in kbps, size in bytes, speed in fps.)
Conclusion #1.
The quality/size difference between esa and tesa is absolutely negligible. While the speed hit is fixed regardless of the search range (~15%), improvements in size are within at most 0.3%, and they happen only at the point where the whole thing is slow as hell anyways. Meaning this time is better spent elsewhere.
Conclusion #2.
Uneven multi-hexagon search at high range outperforms exhaustive in quality/speed ratio until a certain threshold, where motion estimation quality stops rising (see conclusion #3). Exhaustive search can still improve quality in this case, but at an incredible performance hit: up to ~4% reduction in bitrate at up to 10x lower encoding speed. The value is limited by the video's resolution (320 for Genesis).
Conclusion #3.
The sweet spot for umh is ~192, increasing it past this point doesn't hurt speed much, but doesn't return any benefits either. For (t)esa, efficiency drops rapidly after ~160, while setting it to over 200 equals to torture.
