[Bug] Pixel 8 AVC1/H264 1080p60 stutter — clean repro + artifacts

[Priveetee]

Hello @InfinityLoop1308,

Quick follow-up on the AVC1 stutter topic.
I am opening this here with proper technical artifacts.

Like I said here: TypeType issue #1
I kept digging because I wanted hard data, not only user-visible lag.

Related PipePipe threads:

• PipePipe #2074
• PipePipe #2045

Upstream reference investigated:

• Google Issue Tracker #301368768

Context

I now have a clean repro on Pixel 8 with AVC1/H264 1080p60: visible stutter/lag while audio stays in sync.

Repro environment

• Device: Pixel 8 (shiba)
• OS: GrapheneOS BP4A.260205.001
• App tested: InfinityLoop1309.NewPipeEnhanced (release)
• URL: YouTube test video
• Stream forced manually to AVC1/H264 1080p60
• Continuous playback: ~5 minutes

Steps to reproduce

1. Open this video
2. Force AVC1/H264 1080p60 stream manually
3. Play continuously for around 5 minutes
4. Observe visible stutter/lag during playback (audio remains in sync)

Expected

Smooth playback.

Actual

Visible stutter/lag during playback (audio remains in sync).

Log evidence (same 5-minute run)

Repeated signatures:

• c2.exynos.h264.decoder
• Ignoring stale input buffer done callback (5 times)
• BAD_INDEX (5 times)

Representative lines:

04-08 19:07:06.877 I/CCodecConfig(26375): query failed after returning 15 values (BAD_INDEX)
04-08 19:07:07.150 D/CCodecBufferChannel(26375): [c2.exynos.h264.decoder#246] Ignoring stale input buffer done callback: last flush index = 4269, frameIndex = 4269
04-08 19:08:06.933 I/CCodecConfig(26375): query failed after returning 15 values (BAD_INDEX)
04-08 19:08:07.214 D/CCodecBufferChannel(26375): [c2.exynos.h264.decoder#246] Ignoring stale input buffer done callback: last flush index = 7814, frameIndex = 7814

No ANR/fatal crash in this run; this is playback stability degradation.

Control comparison

On the same device, VLC/mpv control runs with H264 content did not reproduce the same visible stutter pattern.

Artifacts

• Full 5-min logcat
• dumpsys media.metrics
• Full bugreport zip: available on request (kept private due sensitive system data)

I’m opening this issue first with full repro data and artifacts so we have a solid baseline.
I’ll now investigate a mitigation/fix path and, if results are good, I’ll open a PR with validation details.
If I can’t fully fix it, I’ll still share findings to move this forward.

[Priveetee]

Update: I ran an isolation pass to separate app/UI from decoder/stream path.

Test matrix (Pixel 8, Android 16, Media3 demo app)

1. Local YouTube sample (downloaded with yt-dlp, AVC1 1080p60, ~100s clip from the same video tjJafDTSdA4)

   • ffprobe: codec_name=h264, codec_tag_string=avc1, 1920x1080, 60000/1001
   • Decoder: c2.exynos.h264.decoder
   • Drops: 100 total (50 + 50) around ~68s

2. Direct YouTube HLS variant (itag 301, AVC1 1080p60) in Media3 demo

   • Decoder: c2.exynos.h264.decoder
   • Drops: 522 total (50,50,50,50,50,50,50,50,122) around ~50-62s

3. Local control file (Sintel AVC1 1080p60)

   • Decoder: c2.exynos.h264.decoder
   • Drops: 0 in the 90s run

Key interpretation

• This reproduces outside PipePipe UI (Media3 demo), so it is not a PipePipe UI-thread issue.
• It is not all AVC1 1080p60 content either (Sintel local is smooth).
• The problematic path is consistent with Pixel 8 Exynos H264 decoder behavior on this YouTube AVC1 stream family, with HLS making it worse.

Representative log lines

• Local YouTube sample:

  • videoDecoderInitialized ... c2.exynos.h264.decoder
  • droppedFrames ... 50
  • droppedFrames ... 50

• Direct HLS 301:

  • videoDecoderInitialized ... c2.exynos.h264.decoder
  • droppedFrames ... 50 (x8)
  • droppedFrames ... 122

• Local Sintel control:

  • videoDecoderInitialized ... c2.exynos.h264.decoder
  • no droppedFrames events in run window

[Priveetee]

I think im gonna test on an another device to see if it is Only pixel related

im gonna run the same test on a Samsung Galaxy Z fold 5

[Priveetee]

Additional cross-device update (no code changes, same test protocol):

Device A: Pixel 8 (Android 16, Media3 demo)

Decoder selected: c2.exynos.h264.decoder

• Local YouTube sample (AVC1 1080p60, ~100s): droppedFrames total = 100 (50 + 50)
• Direct YouTube HLS 301 (AVC1 1080p60, ~90s): droppedFrames total = 522 (50,50,50,50,50,50,50,50,122)
• Local control file (Sintel AVC1 1080p60, ~90s): droppedFrames total = 0

Device B: Samsung Galaxy Z Fold 5 (SM-F946B, Android 16, Media3 demo)

Decoder selected: c2.qti.avc.decoder

• Local YouTube sample (same AVC1 1080p60 clip): droppedFrames total = 0
• Direct YouTube HLS 301 (same AVC1 1080p60 stream family): droppedFrames total = 0
• Local control file (Sintel AVC1 1080p60): droppedFrames total = 0

Interpretation

This strongly suggests the regression is device/decoder specific (Pixel 8 Exynos H264 path), not a general ExoPlayer issue and not PipePipe UI-specific.
HLS on Pixel 8 worsens the drop pattern, but the issue can also appear on local YouTube AVC1 content on that device/decoder.

[Priveetee]

So now im figuring out how the fuck can I fix this I have 0 idea 😂 but i think i can figure it out i now have some track to follow

[Priveetee]

maybe bitrate im gonna test it out

[Priveetee]

quick update: I tested the bitrate hypothesis on Pixel 8 with Media3 demo only (no PipePipe UI path).

all runs used the same decoder: c2.exynos.h264.decoder.

• original local YouTube clip (avc1 1080p60, ~100s): drops vary a lot by run (0 / 101 / 204 / 352)
• same clip re-encoded with ffmpeg at 4 Mbps, 8 Mbps, 16 Mbps (still avc1 1080p60): 0 drops in all runs
• direct YouTube HLS 301 recheck: 310 drops in ~95s

so bitrate alone is not the trigger.
this looks more like a bitstream-specific issue on the Pixel 8 Exynos h264 path, and HLS makes it worse.

next step: isolate which bitstream params trigger it (B-frames / refs / GOP / scenecut / timing).

[Priveetee]

quick update after more local-only tests on Pixel 8 (Media3 demo, same decoder path: c2.exynos.h264.decoder).

new runs:

• original local YouTube avc1 1080p60 sample:
  7 runs -> drops = 0 / 101 / 101 / 102 / 204 / 207 / 352 (unstable but reproducible)
• mp4 remux copy of the same file:
  2 runs -> 204 / 483
• mkv copy of the same file:
  2 runs -> 304 / 870
• x264 re-encodes (still avc1 1080p60), multiple variants:
  safe6 / aggr6 / bf0 -> all runs = 0 drops

nal unit isolation:

• remove AUD only (nal type 9): still bad
  2 runs -> 493 / 559
• remove SEI (nal type 6): stable
  5 runs -> 0 / 0 / 0 / 0 / 0

so bitrate is not the trigger.
the strongest signal right now is SEI-related sensitivity on the Pixel 8 Exynos h264 decode path.
container/timestamp differences can change severity, but SEI removal is the only thing that consistently made the problematic local sample stable in my tests.

[Priveetee]

I think I've found the damn bug

still testing not sure

[Priveetee]

ok proper update

i changed one thing only in the hls path:

• PlayerDataSource.java -> getYoutubeHlsMediaSourceFactory()
• extractor now uses:
  DefaultHlsExtractorFactory(DefaultTsPayloadReaderFactory.FLAG_DETECT_ACCESS_UNITS, true)

what this does:
it changes how hls/ts video chunks are parsed before decode.
with this flag, exoplayer does stricter access-unit detection (real frame boundaries) instead of relying on weaker framing assumptions from the stream.

why this makes it smooth now:
on this avc1 youtube stream family, the exynos h264 path seems very sensitive to how units are split/feeded.
when boundaries are cleaner, the decoder queue is fed in a more stable way, so no big burst/reorder behavior and droppedFrames collapse.

important:

• same stream family is selected (still hls avc1 1080p60)
• no codec force
• no quality force
• only hls parsing behavior changed

A/B on same repro video:

detect-AU ON:

• 7 runs: 0 / 0 / 0 / 0 / 0 / 0 / 0 droppedFrames

detect-AU OFF (control build):

• 3 runs: 13 / 312 / 573 droppedFrames

also, direct signed itag url tests can still hit 403 because of signature/expiry/ip constraints, unrelated to this parser change.

about scope:
i don’t think this is only Pixel 8.
it likely affects devices on the same exynos/tensor h264 decoder path (c2.exynos.h264.decoder), so probably multiple Pixel generations.

[Priveetee]

im gonna check if i can find on google if all google pixel has the same decoder

[InfinityLoop1308]

Thanks. As in #24 , it is merged.
But I forget a thing: hls is only used by YT after 4.9.0 with account logged in 🤔 how can it solve the issue?

[Priveetee]

clarification on your question:

this fix changes one place only:
PlayerDataSource#getYoutubeHlsMediaSourceFactory()

and it is executed only when resolver selects DeliveryMethod.HLS (youtube logged-in path in 4.9.x).

my validation setup was exactly that path:

• app: 4.9.0
• youtube account logged in
• resolver logs: Candidate video delivery counts: {HLS=...}
• selected stream: delivery=HLS, AVC1 1080p60, itag 301

A/B on the same setup:

• detect-AU ON: 0/0/0/0/0/0/0 droppedFrames
• detect-AU OFF: 13/312/573

so with current data, we consider this issue fixed after merge/deploy.
if new user reports appear after rollout, or if I reproduce it again myself, I will reopen investigation immediately.

[Priveetee]

but now im curious I want to test without be logged in