Audio Pop/Click on Roku Express 4K+ Plex AAC 5.1/7.1 Surround

This is just a quick post about a dumb problem that I had a lot of trouble pinning down: audio popping on my Roku. The tl;dr is: set "direct play" to "auto" instead of "forced." If you'd like to understand why, keep reading.

Background

I got a new TV recently--a Hisense U7H--to replace my crappy, ultra-budget TCL 4-series Roku TV. I was planning to use the built-in Android OS to run the Plex app to stream media from my local server but the app apparently sucks in a number of strange ways, especially when it comes to music and playlists, so I bought a cheap Roku Express 4K+.

The Problem

Some of my videos started having an annoying popping/clicking in the audio. I tried the same videos with the native Android app and that resolved the clicking, so I was pretty sure it was Roku-specific. From there, I did some googling and came up with some possibilities: apparently Roku OS 10 has some sort of issue with AAC and AC3 streams, and there are some issues with Roku's "audio leveling" feature. I tried reencoding the audio on a persistently popping video from AAC to AC3 and the popping went away, so I don't think it was the OS 10 issue, and I didn't have the audio leveling enabled in the first place, so it didn't seem to be that one either.

Additionally, I tried playing the offending video on Jellyfin to rule out any Plex-specific issue and popped/crackled there, too.

One of the posts in the audio leveling thread caught my eye, though:

With a little more searching, I learned that Roku devices apparently cannot playback AAC via hardware at all(?) and will, at best, convert them to something else, but they apparently don't have the grunt to decode multi-stream audio--like 5.1 or 7.1 surround--at full speed, which results in the popping.

The Solution

The solution appears to be changing the "direct play" setting in the player/client from "force," which I had selected to minimize the CPU load on my server, to "auto." Your server will have to reencode the audio more often, but it should get rid of the pops.

A Brief Look at x265 vs x264

The next-gen open-source video codec known as x265 (h.265 / HEVC) is starting to gain some traction, since it is now included in the popular FFmpeg utility and its various derivatives, so I figured I'd do some poking around and see how it compares with the ubiquitous x264 (h.264 / AVC). NOTE: x265 is still extremely new and unoptimized, while x264 is mature and stable, so this isn't really a fair fight just yet.

For this comparison, I downscaled a 720p video to 480p with both codecs. For x264, I used a CRF value of 21, high profile, 'medium' quality preset with a 'film' tuning (these settings were chose for simplicity rather than quality). For x265, I used an RF value of 21, 'medium' quality preset with 'ssim' tuning.

During the encoding, x264 used all 8 of my AMD Bulldozer cores at approximately 95% utilization, with an average encoding speed of ~75 fps. In comparison, x265 reached only approx. 65% CPU utilization, with an average encoding speed of just 12 fps.

As expected, the videos were comparable in quality, with a slight edge going to x264 (maybe related to differences in my settings, or maybe differences in the codecs, themselves; I'm not sure and didn't delve deep enough to find out), as you can see in these sample shots (click for full size, which is still pretty small):

x264

x265

x264

x265

However, underlying that slightly better quality, x264 used roughly 47% more bits per second to encode. That is, x265 had a final bitrate of 624 kbps vs x264's 919 kbps.

So, x265 already produces a significantly more efficient encoding than x264 but the processing power required for that encoding is much greater (roughly one-sixth the framerate). Moreover, decoding is all done on the CPU right now, as no GPUs have built-in decoder chips for h.265, so that means greater power usage and shorter battery life when viewing.

x265 is already impressive in efficiency but the drawbacks of increased computational costs in both encoding and decoding and drastically slower encoding speeds make it currently unattractive to me. I'll be keeping a close eye on development, though, since it's only a matter of time before the tradeoffs are corrected (improvements in the codec), negated (implementation of hardware encoding/decoding) or rendered moot (improvements in general computation power). After all, it wasn't so long ago that x264 was considered immature, unoptimized and poorly supported in hardware vs xvid / ASP. ;)