Upload a local file or paste a URL, then click Play. Observe the metrics panel for drops/stalls.

Decode compatibility, playback stability, frame drops, and Audio/Video sync.

unnecessary. The test is based on browser capabilities (such as MediaCapabilities, HTML5 Video, Web Audio) and can be used by opening the page.

When using local file testing, the video will be decoded and played locally in your browser and does not need to be uploaded. If you paste an online video address, the browser will request the address resource just like watching a video normally.

The common MP4 (H.264) usually has the best compatibility; WebM (VP9/AV1) performs better on some browsers. Whether HEVC/H.265 is available is related to operating system/browser authorization (for example, some environments support it and some do not). If it cannot be played, it is recommended to change to H.264/MP4 or test again directly using local files.

Common reasons include: the link is not a "direct link" (it is actually a web page rather than a video file), the resource requires login/authentication, the server does not allow cross-domain (CORS), or the browser does not support the encoding/encapsulation format. It is usually more stable to test with local files first.

Some browsers intercept autoplay when no user gesture occurs, or simply fail when the resource is not supported. Please click anywhere on the page, then click "Play", and try "Play from the beginning/Reset"; if it still fails, change to a video with a more universal encoding (such as H.264/MP4).

Please check whether "Mute" is turned on, whether the system volume/output device is correct, and whether the video itself has an audio track. If you use a Bluetooth headset/external sound card, you may not be able to hear the sound due to output switching. It is recommended to temporarily switch back to the system's default output and try again.

You can focus on the "number of waiting/stuck times" and "total jam duration": the more times and the greater the total duration, the worse the subjective experience. If the lag occurs intensively when dragging the progress bar (seek) or when buffering is first started, it may be biased towards the network/buffering; if it continues to occur, it may be a decoding or performance bottleneck.

Frames the computer skipped because it couldn't render them in time. Causes stuttering.

Different browsers may have different codecs, hardware acceleration strategies, power consumption strategies, and sandbox limitations. It is recommended to compare the performance of Chrome/Edge and Safari/Firefox at least once, especially for encodings with greater differences such as HEVC, VP9, ​​and AV1.

Yes. It offloads tasks to the GPU. Ensure it's enabled in browser settings for 4K video.

If you want to test "daily playback", you can use 1080p@30; if you want to stress test performance, you can use 1440p/4K or 60fps (such as 1440p@60, 1080p@60). Comparing different gears on the same device makes it easier to determine whether the bottleneck comes from decoding or rendering.

It will ask the browser about its support for a specific combination of encoding parameters (whether it is supported, whether it is smooth, whether it is powerEfficient). This can help you predict before playback: certain codecs/resolutions may be "playable but not smooth" in your environment.

This means that the current browser cannot automatically detect decoding capabilities (support/smooth/power saving). It does not affect the basic playback test. You can still judge by observing stuttering, frame loss and subjective experience through actual playback.

Click "Audio and video synchronization self-test (splash screen + beep)" and observe the relative order of "seeing the splash screen" and "hearing the beep": If it feels inconsistent for a long time, there may be audio link delay or desynchronization caused by system processing.

Relatively common. Bluetooth link codecs, system audio enhancements, and buffering strategies for different output devices can all introduce perceptible delays. It is recommended to use wired headphones/speakers to retest and compare, or turn off "Audio Enhancement/Spatial Audio" in the system and test again.

Video decoding and rendering will occupy CPU/GPU/memory bandwidth; high background load (games, conferences, screen recordings, browser multi-tabs) will increase frame interval jitter, thereby increasing stuttering/frame loss. It is recommended to close high-load programs and then retest as a "pure video performance" comparison.

Probably. Full screen or picture-in-picture will change the rendering path and refresh rhythm. On some devices, the difference is more obvious on external monitors/high refresh rate screens. It is recommended to test once in "Windowed Mode" and "Full Screen/Picture-in-Picture" to see if the lag and frame loss change.

It is recommended to troubleshoot in order: first use local files (exclude network/CORS) → switch to the more universal encoding H.264/MP4 (exclude compatibility) → switch browsers (exclude implementation differences) → turn off background high load/switch hardware acceleration (positioning performance/driver). Usually 2-3 steps will identify the main cause.