Video playback in Brave on Android stutters constantly. It's most obvious during slow camera pans or scenes where not much is moving — it looks like the video is running at a lower frame rate than it should. Fast action hides it, slow movement makes it obvious.
This is not site-specific. It happens on every site with video, and it also happens with a local file opened directly in the browser. The same files play perfectly in Chrome, in Firefox, and in the phone's native gallery player on the same device. Only Brave. It reproduces on Nightly, so this is still live in current code.
The important part: if I scroll the page continuously while the video plays, the stutter goes away. The moment I stop scrolling, it comes back. This is repeatable. It looks like frame presentation is only being scheduled properly when something else forces the compositor to tick.
Evidence from brave://media-internals
Local 24fps H.264 High file, 1280x544, no network involved:
kVideoDecoderName: MediaCodecVideoDecoder
kIsPlatformVideoDecoder: true
info: Created MediaCodec c2.qti.avc.decoder, is_software_codec=0
kFramerate: 24
kVideoPlaybackFreezing: 0.025115
kVideoPlaybackRoughness: 116.802
video_buffering_state: BUFFERING_HAVE_ENOUGH (never dropped below this)
So: hardware decode is active, nothing is freezing, nothing is starved for data. The frames are decoded and delivered fine, they're just being presented at very uneven intervals.
For reference, 24fps content on a 60Hz panel produces at most ~8ms of cadence error from 3:2 pulldown. 117 is an order of magnitude past that, so this isn't ordinary judder.
Combined with the scrolling workaround, it points at frame presentation scheduling rather than decode or delivery.
Steps to reproduce:
- Play any video in Brave on Android, ideally something with a slow camera pan
- Don't touch the screen — stutter is visible
- Scroll the page continuously while it keeps playing — stutter disappears
- Stop scrolling — stutter returns
Already ruled out:
- Shields off for the page: no change
- Display refresh rate forced to 120Hz (24fps divides evenly into it): no change
- Hardware decode: confirmed active, not falling back to software
- The file: plays smoothly in the native gallery player and in other browsers on the same device
- Network: reproduced with a local file
*Environment
- Brave: 1.92.144
- Device: OnePlus Nord 4 (Snapdragon 7+ Gen 3, 120Hz panel)
- Android: 16
- Reproduces on Nightly: Yes
Stock hardware and current Android, nothing exotic in the setup. The Qualcomm decoder in the log matches the SoC.
Possibly related: #15007 (closed as stale), #53834.
Video playback in Brave on Android stutters constantly. It's most obvious during slow camera pans or scenes where not much is moving — it looks like the video is running at a lower frame rate than it should. Fast action hides it, slow movement makes it obvious.
This is not site-specific. It happens on every site with video, and it also happens with a local file opened directly in the browser. The same files play perfectly in Chrome, in Firefox, and in the phone's native gallery player on the same device. Only Brave. It reproduces on Nightly, so this is still live in current code.
The important part: if I scroll the page continuously while the video plays, the stutter goes away. The moment I stop scrolling, it comes back. This is repeatable. It looks like frame presentation is only being scheduled properly when something else forces the compositor to tick.
Evidence from brave://media-internals
Local 24fps H.264 High file, 1280x544, no network involved:
So: hardware decode is active, nothing is freezing, nothing is starved for data. The frames are decoded and delivered fine, they're just being presented at very uneven intervals.
For reference, 24fps content on a 60Hz panel produces at most ~8ms of cadence error from 3:2 pulldown. 117 is an order of magnitude past that, so this isn't ordinary judder.
Combined with the scrolling workaround, it points at frame presentation scheduling rather than decode or delivery.
Steps to reproduce:
Already ruled out:
*Environment
Stock hardware and current Android, nothing exotic in the setup. The Qualcomm decoder in the log matches the SoC.
Possibly related: #15007 (closed as stale), #53834.