I don't have an opinion on which codec is best or should be used. I started the thread because I was pleasantly surprised H265 was playable in CPU (with -tune fastdecode) and wanted to share that.

Whether ~65% or ~95% CPU load is preferable for you is a personal choice. For more battery life, I hooked up a 3800mAh battery. Droid4 is very tolerant of that (even in android), but you lose battery life estimation in software.


[EDIT] A sample encoding to illustrate the lesson:

Nonsuch's script refers to encoding guidance from https://videoblerg.wordpress.com/201...-use-it-wrong/

Please do notice right at the beginning the author, Navilor, writes:

"’Ive been in the streaming media industry since 2008".
And:
"I like to make sure that my content uses all of the bells and whistles for delivering bitrate based content..."

That is stating clearly that he is encoding for streaming video which has hard limits on maximum bitrate due to the slow network carrier. This not our use case and it's very important to understand why it matters.

Contrary to Navitor's streaming-video use-case, encoding for local playback is not constrained by a low maximum bitrate. This is why encodes for local playback use different encoding parameters and/or algorithms than ones for streaming. Encodes for local playback aggresively reduce bits per second in low-complexity scenes, and use lots of bits per second in complex, high-motion scenes. This provides the viewer with a constant perceptual quality at the smallest possible filesize.

Given that N900 and Droid4 cpu playback cannot handle full resolution h264 or h265 playback with "-profile:v high -tune film" with either libx264 or libx265, quality comparisons must be done using -tune fastdecode.

Let's take for our test movie Seijun Suzuki's "Zigeunerweisen" (1980), encoded with h265 crf 29 and libopus audio. At two hours and 24 minutes running time, a 720x540 h265 encode, which looks fine on the Droid4 screen, comes to just 179MB.


Notice the huge bitrate spike of ~2500kbit/s around 1:38 -- that kind of unpredictable spike is generally unacceptable for streaming, and it's the reason two-passes are used, to find them ahead of time, and spread out the available bits optimally in time. But does it also cause problems for mplayer on Droid4?
Apparently not! Both mpv and mplayer manage the 1500-2500kbit/s scene without the dreaded "too slow to play this" or "can't keep up!" warnings.

Let's look closer at h265 crf in the region 1:36-1:40 which contains scenes exhibiting a wide range of complexity.

1. person in front of static background
2. sun with heat waves
3. tree blossoms waving in wind
4. person in front of falling petals

ffprobe reports the h265 encode over the whole movie has a mean bitrate of 173kb/s.

Let's try encoding two-pass h264 with bitrate set per nonsuch's script, but using fastdecode for Droid4 playability and audiocodec 28kbit/s libopus - same as the h265.

I'll give h264 173kbit/s target with parameters based on nonsuch's script, with a bit extra headroom: bufsize = 216+28 = 244kbit/s and maxrate = 216+72 = 288kbit/s.
(this just the first pass - for second pass give it an output file and change -pass 1 to -pass 2)

This yields a 208MB file at 201kbit/s, 16% larger than our h265 crf.
Let's have a look at the bitrate graph and results:



Notice the following:

• The h265vb bitrate variance is much less than in the h265crf encode: The simple scenes use more bits per second and the complex scenes use less.
• The first two low-motion scenes are acceptable for a small phone screen,in both encodes, though h265 delivers less blockiness at lower bitrate.
• The tree blossoms in the bitrate-constrained h264 consume around 345kbit/s versus h265crf's~1500kbit/s. This limitarion, compounded by the more primitive h264 encoding, makes the scene completely unrecognizable.
• The woman on phone encoded with h264 with peak ~300kbit/s is an abstract mess versus the clear picture h265crf gives her with peak ~500kbit/s.

20 second video samples from h265-clort
http://0x0.st/-OYW.mkv
and h264-nonsuch:
http://0x0.st/-OY4.mp4

And that, ladies and gentlemen, is why we do not use two-pass bandwidth-limiting streaming optimizations for local-playback encodes of h264 and h265.

Cheers