Improve Seeking Performance for Long-GOP AVC/HEVC Files on Android TV / NVIDIA Shield

Plex Players Mobile Devices
1

Platform Details

  • Plex Client: Android TV app 10.30.6.4151 (running on Shield 2019)

  • Server: Plex Media Server 1.42.2.10156 (Windows)

  • Playback Mode: Direct Play (no transcoding)

Problem Description

The Shield client struggles to seek smoothly in files encoded with long GOP structures, e.g.:

  • AVC / H.264 with max-keyint = 192–240

  • HEVC / H.265 with max-keyint = 192–240

Symptoms during scrubbing / seeking:

  • Delays of 1–5+ seconds before video resumes

  • Partial buffering or “Try again” message

  • Inconsistent behavior depending on timestamp or seek direction

Other clients (VLC) on the same hardware seek instantly, indicating this is client software behaviour, not hardware limitation.

Technical Reproduction Instructions

  1. Prepare Test Files
    Encode sample clips with ffmpeg (any short movie or test video):
# AVC example
ffmpeg -i input.mp4 \
-c:v libx264 -preset slow -crf 18 \
-g 192 -keyint_min 192 \
-c:a copy \
-c:s mov_text \
-movflags +faststart \
output_avc_192.mp4

# HEVC example
ffmpeg -i input.mp4 \
-c:v libx265 -preset medium -crf 20 \
-x265-params keyint=192:min-keyint=192 \
-c:a copy \
-c:s mov_text \
-movflags +faststart \
output_hevc_192.mp4

  • -g or keyint= 192 sets the GOP to ~8 seconds at 24 fps.

  • Subtitles and audio are preserved (mov_text, copy AAC/AC3).

  • +faststart ensures MP4 can start playback immediately.

  1. Place the file in Plex Library

    • Ensure Direct Play is enabled.

    • Disable automatic transcoding for this file.

  2. Test Seeking on Shield

    • Open the Plex Android TV client.

    • Play the file from the start. Observe it plays (Direct Play)

    • Scrub forward/back, jump to random timestamps.

  3. Expected Behavior

    • Playback should resume instantly, without buffering or delay.

  4. Observed Behavior

    • Playback stalls briefly or fails to resume for 1–5+ seconds.

    • Longer keyint → more pronounced delays.

    • If transcoding is enabled, it will report playback has failed and fallen back to transcoding

Suggested Improvement / Fix

  1. Frame Index Optimization

    • Implement efficient partial decode logic for long-GOP files.

  2. Optional Client Setting:

    • “Enhanced Seeking Mode” to pre-decode frames around seek points for smoother scrubbing.

  3. Backward Compatibility:

    • No impact on short-GOP or pre-encoded files.

    • Only affects Direct Play streams.

Why This Matters

  • Long-GOP encoding is common for high-quality Blu-ray / streaming encodes (~24fps, CRF 18–22).

  • NVIDIA Shield is a flagship Plex client; smooth seeking is expected.

  • Current behavior leads to poor UX even with high-end client hardware.

2

Other clients (VLC) on the same hardware seek instantly, indicating this is client software behaviour, not hardware limitation.

You might be looking at that halfway backwards. Plex very likely gives the stream directly to the Shield hardware for decoding. While VLC very possibly uses software decoders.

Do you notice, does VLC begin playback at the requested timestamp, or at a GOP/IDR boundary?

Long-GOP encoding is common for high-quality Blu-ray / streaming encodes (~24fps, CRF 18–22).

BD and UHD BD and most streaming formats specify 1 or 2-second GOPs. That’s mostly because it’s a good compromise for compression efficiency and seek performance on bandwidth- and decoder- limited equipment (such as the Shield).

You mean recompressed content, I assume?

3

Plex for Android TV on this Shield is using the Nvidia decoder (assumed to be the hardware decoder since there is no toggle to choose otherwise) in Android and the toggle was removed years ago in the Plex client.

VLC has the option and it is set to hardware decode.

Plex is seeking to the exact timecode in the stream, backwards 10 seconds and forward 30 seconds. This incurs some lag by this implementation and seeking/scrubbing through the stream results in mostly the buffering animation while its probably performing a lot of frame rendering that gets thrown away.

VLC (Android TV DNLA client) is seeking to the nearest GOP boundary and plays from the starting I-frame in the GOP, meaning seeks do not go exactly to the timecode but this process is extremely responsive and you can seek/scrub through the stream at a fast rate and see the picture (I-frames) which are decoded fast.

Content is re-compressed (how many of us have uncompressed/lossless content) for high-quality archival. This means compression efficiency is important. Note: BBC Streaming iPlayer content has a GOP of 8 seconds.

In summary Plex for Android struggles where iPlayer and VLC do not.

4

I’m sure you can play these long GOP files with desktop player just fine.

However, Plex is a streaming server. Playing video over a streaming network protocol is different from a desktop player which has direct file access.
My recommendation would be to not muck about with the codec parameters, apart from coding “speed” and target bitrate / or quality factor.
The default parameter sets used by these codecs are selected to give you video files which are suitable for a variety of uses.
I’m sure your long-GOP files are smaller than regular files.
But the price you’re paying for this is that your files are no longer universally usable. They play fine on desktop players with direct file access. But they are sub-optimal for streaming use – particularly when going for higher than average picture quality/higher bitrate.

5

I was not using VLC for direct file access for this. It was as close to a “like-for-like” comparison as you can have. VLC is streaming my personal content over the local network using the DNLA protocol onto my Shield Android streaming box and is not the desktop client. VLC is a more universal player held in high esteem and works exceptionally well with local, remote and many streaming sources. It was used to demonstrate what is possible on the Shield TV platform which is also extremely performant, despite its age. The Plex client now, unfortunately, has a lot of detractors due to its deficiencies, as has been posted elsewhere I’m not going to go into. I am hopeful that Plex can recognise its roots and continue to be a strong proposition for us who still want to stream private content from our own media library. If not, please advise what we need to do.

Default parameters: “HEVC is a codec and there is no default GOP length for a codec. It is encoders that have a default GOP length. For both x265 and nvenc, it is 250.”

So on that one, the default settings are outside the 2 second GOP that works best with the current Plex client, meaning this parameter (-g or keyint) and some others need to be explicitly chosen for smooth Plex playback after seeking/scrubbing.

6

If your files have very few IDR/CRA frames the only thing Plex could do would be to transcode. There’s no feasible way to “enrich” a stream for seekability without re-encoding.

Or Plex could copy VLC’s low-fidelity seek behavior in the client, but that’s a big tradeoff.

7

Just to clear up some confusion, my encode settings produce re-compressed files using a dynamic GOP of between 1 and 10 seconds according to the type of content, so fast moving and scene cuts will produce extra IDR/CRA frames when needed. These files play well generally but can stutter (sometimes fail) on seeking/scrubbing especially if a large GOP is encountered somewhere. I analyzed one of my files and measured that the average GOP size was 2.6sec, with a minimum of 1 sec & maximum of 10 sec. Thus I’d have around 1000 key-frames in a 40 minute file of studio recorded content. I feel this is adequate for good seeking.

The settings I provided to start with (8 second GOP which are not typical of my encodes) are to force the unwanted behavior in Plex, I find it plays perfectly in VLC (Android DNLA client), LG TV built-in DNLA client and apparently it is good for AppleTV.