To my great surprise, 24-30 fps full resolution HEVC (h265, libx265) encoded videos can be played back under Maemo-Leste, on Droid 4 with cpu alone!

By keeping bitrate low and using the -tune fastdecode option, mplayer (and sometimes mpv) has no trouble keeping up with the video! Very small filesize, acceptable small screen quality. Much joy!

Here's a sample ffmpeg line i just encoded with:
ffmpeg -y -i $1\
-filter:v "hqdn3d=0.0:0.0:7.0:7.0,smartblur=1.9:-.24:0.09:1:0.0:0.0,scale=960x540,setsar=1:1,eq=con trast=1.20:brightness=0.08:gamma=1.15"\
-filter:a "volume=1.4"\
-movflags faststart -c:v libx265 -crf 30 -pix_fmt yuv420p -preset medium -tune fastdecode -auto-alt-ref 0 -metadata:s handler_name=ClortVids\
-c:a libopus -b:a 56000 -frame_duration:a 60\
out.mkv
So this 2 hour film came in at about 280MB. 32 seconds is just 560kB.

http://0x0.st/-pE1.mkv

h265 does great for lectures, with static backgrounds.
http://0x0.st/-pEf.mkv

Playback cpu% (one core) on the omap4 is ranging from 75-98%, so higher bitrates and/or framerate films could be problematic.

Still, it's very nice for me. Small files, films and lectures watching on-the-go!

Great that it works at all!

However:
how hot, how long before the battery runs out...?

My experiments with x265 vs x264 showed me that a carefully encoded x264 video is only insignificantly larger compared to an equal quality x265-encoded file, while using much less resources (even if the GPU supports HEVC decoding).

I think x265/HEVC makes most sense for streaming, because smallest possible file size.

Can you share your parameters and results @nonsuch?

I'll show you an example:

H265: -movflags faststart -c:v libx265 -crf 27 -pix_fmt yuv420p -preset medium -tune fastdecode -auto-alt-ref 0 -metadata:s handler_name=ClortVids
FILESIZE = 1.996 MB

H264: -movflags faststart -c:v libx264 -crf 23 -pix_fmt yuv420p -preset medium -tune fastdecode -auto-alt-ref 0 -metadata:s handler_name=ClortVids
FILESIZE = 3.933 MB

Results: h265 on top, h264 on bottom

Notice the color quantization, pixel blocking.
Video results:
H264 http://0x0.st/-fL3.mkv
H265 http://0x0.st/-fL4.mkv

At least with these parameters H264 looks worse even at twice the filesize of H265.

Cpu use with mplayer vieweing 24fps 960x540 is at 55-75% with h264 and 75-105% with h265. The encoding time for h265 is about 10x slower.

This is the only thing I was refering to.
And if you do a proper 2-pass encoding of x264 you can tweak it so that it's just as good as x265, while being maybe 25% larger in filesize.
- But it makes a huge difference during playback (CPU usage).

I did actually do this once, let's see...

Here's the script I wrote, takes a while to get into it, but then it compares x264/x265 pretty straightforwardly:
(script deleted because it is known to suck, and not the point of this discussion)

I see the source of confusion nonsuch.

You set bitrate with -b:v and -maxrate, instead of using the encoder designer's quality preset (crf). That is an error.

For local playback with both H264 and H265, ffmpeg documentation instructs to use a single pass encode with the crf parameter, not two-pass limited bitrate. With H264 and H265, unlike some prior encoders, two-pass is only superior for encoding to a specific filesize and the maxrate parameter is used to limit bandwidth for streaming.

Your settings waste bits in H264 and H265 during more-compressable scenes, but they hurt H265's efficiency more because it is better at rendering simple, low motion scenes at very low bitrates. The crf algorithm more aggressively varies bitrate than the -b:v one.

In summary: You have not found better encoding for H264 -- you're misusing both of them, but you're degrading H265's efficiency more. By doing-so, your H264 encodes look relatively better vs H265 than they should be.

Hope this helps anyone browsing the thread.

Thanks for your advice. You might be right. Encoding video is an artform.

But I also notice that you are not using 2-pass encoding, so the jury is still out on that.

Anyhow, all that does not change the fact that there's little point in pushing the CPU to decode x265 on a device that needs every ounce of battery life - as your own numbers show.
And certainly you have enough free space on your SD card so that even a 100% increase in size does not matter? Or at least, matters less than draining the battery?
I'm thinking of an out-and-about use case; you seem to be using your Droid 4 at home, probably permanently hooked up to USB charging?

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

oh and p.s. The h264 with the maxbitrate formula from that streaming video site is still unusable at 304MB - +70% larger.

While we're at it, let's run a plot of the SSIM score of both 4 minute encodes.
https://en.wikipedia.org/wiki/Structural_similarity

Somewhat surprisingly the SSIM score of the unrecognizable h264vb tree blossoms aren't much lower than the recognizable h265crf ones. Human subjective perception of visual quality is modeled better with Netflix's neural-network based metric but i don't have time for that one.

Power use measurement: h264vb vs h265crf

Droid4 backlight was set to level 5/7 - good for normal room brightness.

echo 5 > /sys/class/backlight/backlight/brightness

The same beginning time as above excerpts were used from the movie, but running for 10 minutes (600 seconds) to get a better power estimate. Mplayer was used since it's fastest player currently in repository.

mplayer -vo x11 -fs -ss 01:36:00 -endpos 600

Power use was tracked once/min for 10 minutes with Droid4 powermanagement script from repo:

/etc/init.d/droid4-powermanagement status > poweruse_h265.txt

CPU use was tracked once/10sec for 10 minutes with pidstat:

pidstat -C mplayer -u 10 60|grep -v PID > cpuuse_h265.txt

The output files are attached in a .tgz

Zigeunerweisen results

CPU H264vb: 41.2%
CPU H265crf: 58.9%

Discarding the first power reading (it hasn't yet registered a full minute of video playback) we take the mean of 9 readings:

Power H264vb: 1427 mW
Power H265crf: 1760 mW

Note this movie was low-motion, 720x540 and quite easy on the CPU at 58.9%. More action-oriented 960x540 movies tend to push h265 CPU use into the 75-95% range.

The EB41 battery is rated at 6.6 watt-hours, but even my best replacement batteries deliver only approx. 5.5 watt-hours. This means watching these encodes for 2 hours would use approximately:

h264vb 53% of battery
h265crv 64% of battery

For the whole movie, the tested h265crf encode would require a bit less than 20% more total energy than the h264vb, since the high power peak included is a larger percentage of the sample than the whole movie.

The high-motion tree blossom scene in h265 at around 1500kbit/s pushes CPU to 93.4% and power drain to 2076mW, versus 46% and 1472mW on the bitrate-limited h264. Based on that peak we can infer that a high-bitrate two hour movie using 90+% of one CPU core would consume around 4.1 watt-hours, or 75% of a typical old EB41 battery.

Notice that power use does not scale linearly with CPU use since we have fixed costs like backlight. This is why the 43% higher CPU use of HEVC in this test only costs half as much additional energy.