JDPFu.com 2025

Playback Hardware

For people with Core i3 or faster CPUs, the video codec really doesn’t matter for playback. Their CPU can decode whatever is needed without stuttering. But for people with tiny devices like a Roku-stick or Fire-Stick or Chromecast or Raspberry Pi, hardware-support is mandatory to make hidef video playback possible.

Example Transcodes

Input and Settings

For example, I recorded a locally produced, 20 min TV show OTA. The original file was MPEG2. Removed all the commercials using comskip and transcoded using handbrake with a 19.5 Constant Quality setting for the video and added both AAC, VORB and retained the AC3 audio. Also, reduced the resolution from 1080i to 720p.

Resulting File Sizes

$ du -sh Atl*
2.0G    Atlanta_Tech_Edge-2016_12_25.mpg
443M    Atlanta_Tech_Edge-2016_12_25.mkv
298M    Atlanta_Tech_Edge-2016_12_25-vp9.mkv

The VP9 video file is about 50% smaller than h.264 encoding. It took much longer to create – significantly longer.
To get a feel for the size differences:

xxxxxxxxxxxxxxxxxxxx

xxxx/

xxx

mpeg2, h.264, vp9, respectively. The difference between vp9 and h.264 really isn’t THAT much compared to mpeg2 video.

Transcode Time

I didn’t time it, but transcoding takes about 50% of real-time, so 10 min for h.264. The VP9 transcode took over an hour, so call it 6-7x longer. That might not matter for a one-time transcode of a movie.

Playback Issues On a Raspberry Pi v2

My Raspberry Pi has the MPEG2 hardware decoding enabled. I paid the $1.86 to get that. It does not have the h.264 hardware decoding enabled, but I understand it is enabled in the GPU by default. No license required.

MPEG2 on Raspberry Pi

Playback of the mpeg2 file appears perfect at 1080i and uses about 20-55% of 2 CPUs. 1 CPU (out of 4) is barely touched. Audio is 5.1 DD. As for file sizes, 2 audio tracks are inside the recorded file. DD 5.1 and DD 2.0 (stereo).

H.264 on Raspberry Pi

Playback of the h.264 file appears perfect at 720p and uses about 10-25% of 3 CPUs. 1 CPU (out of 4) is barely touched. Audio is ogg-vorbis 5.1. AAC 5.1 audio does not appear to alters the CPU use in a measurable way. I just prefer ogg for smaller sizes.

There are 4 audio tracks in this file. AC3 5.1, AAC (chromecast), and 2 ogg-vorbis versions 5.1 and stereo.

VP9 on Raspberry Pi

Playback of the 720p vp9 video stutters badly on the Pi. This means that vp9 is not an option for my use without having the Plex server performing real-time transcoding. As a standard playback method, I’m unwilling for that to be necessary. CPU utilization was consistently over 85% across all 4 CPUs. Video and audio was not sync’d. Every 20 sec or so, the video would block up completely. It is useless on the Pi.

Transcoding from Plex Server
PlexBMC on Kodi has been mostly broken for about 2 months here. This makes testing while forcing transcoing impossible.

Testing on Roku v3

My Roku is mainly used to watch Amazon video. It isn’t used for Plex or local media much, so I’m not positive the issues listed below are truly due to the Roku.

The Roku cannot play MPEG2 video files using the Plex Roku addon. Don’t know why, because my Plex server can transcode on the fly as needed, but it didn’t with the test video.

For h.264, the video playback was perfect. Audio was a different issue, but mainly due to the connected computer monitor limitations for audio. The monitor only supports PCM. No DD, no ogg, no ACC, none of the other normally supported playback methods. Conversion to the required audio format – either DD or PCM or stereo AAC from Amazon works well, but I’ve never been able to get the roku to handle other audio format playback with this monitor. It screeches for any audio it doesn’t understand. Very unpleasant.

For vp9, the video playback was perfect. This surprised me. No stuttering. The audio playback persisted, however. With my current monitor playback, this is completely unacceptable and useless.

Testing on Chromecast

For the chromecast testing, I had to use an Android tablet to control the Plex media server and cast-to the chromecast using BubbleUPnP app. My chromecast is the 2015 model, wifi only. The Plex Server transcodes many files for it, but not the VP9 one for some reason. The VP9 test video restarted over and over and over. No video was displayed.
H.264/AAC and h.264/vorbis worked perfectly. That is to be expected.
The original source file never plays on the chromecast. It doesn’t like mpeg2/AC3. Never has.

Older Video Players

None of my older video players handled vp9. h.264 was just becoming normal when those devices were purchases, so that is to be expected. The h.264/ac3/aac/vorb support on them was perfect. Additionally, they handled the mpeg2/ac3 perfectly too. That is expected, since that was the main media types available when these devices were built.

Problems With My Testing

• Only 1 file tested.
• Talk show format. No high action scenes.
• mpeg2/ac3 input file. This is what TV recordings will be here for the next few years.
• Used my normal transcode settings for h.264 with vp9. Don’t know if this is good or bad.
• Used Handbrake v1.0.0 (which actually locked up the system the day prior).

Summary

For my needs, vp9 is not yet ready. h.264/aac/vorb are really the best options for average needs. Once VP9 vcodec support is added to GPUs/HW, then it might be an option.

I’ll have to continue transcoding recorded TV from mpeg2/ac3 into h.264/vorb for the best support on my current hardware and just accept the larger file sizes required. A 75% reduction in size from the mpeg2 source that h.264 provides is still awesome. If I wanted to be even more frugal with storage, I’d remove the AC3 audio and only have vorbis.

In my testing of AC3-DD and AC3-DTS, comparing it to Vorbis 5.1, I cannot tell the difference in resulting output. The DTS is better than than Dolby-Digital, but converted vorbis audio from either sounds like the original to me, given sufficient bitrates.

There’s a handy blog article about VP8 vs VP9 that lead to this article.