Testing¶

Have you tested a player? Please contribute

This guide wants as much evidence as possible behind every claim in the player comparison. If you have tested one of these players, or another player relevant to UHD Blu-ray remuxes, in an objective and repeatable way, your results are welcome: an HDMI capture, a measurement against a known reference, a controlled listening test or a carefully documented observation.

Say what you tested, with which versions and settings, how you measured, and what the result does and does not show. Negative and inconclusive results count too. How to submit.

External tests used in this guide¶

These are the outside tests and registers the comparison currently relies on. Each entry says what it shows and what it leaves open. Links point to the original material; none of it has been repeated locally.

DMDreview: Dolby Vision FEL and real 12-bit output¶

Source: video, 28 October 2026 (Russian) · the author's AVS Forum test thread · earlier LibreELEC forum discussion
Tested: Ugoos AM6B+ (CoreELEC), Dune HD Pro One 8K Plus, an OPPO UDP-203 clone (M9201) and an Intel Core i3-12100 PC with a LibreELEC Dolby Vision test build.
Shows: the author unpacks the TV-led HDMI signal back into 12-bit values with his own software and compares them with synthetic reference images. The enhancement layer contributes on all four devices. The PC matched the reference most closely; the Ugoos merged some neighbouring values; the Dune composes in 10-bit and imitates 12-bit with dither.
Does not show: motion. The author describes the results as coming from test reference images, "not films" (about 19:21–19:31); the comparison is of captured frames against a still reference, so frame pacing, judder, dropped frames and how dither behaves over time are not covered. Nor does it show real films, the capture hardware (not named in the captions read), exact firmware or builds, AMD PCs, a genuine OPPO, or whether the differences are visible. The author's ranking is his own.
Evidence: independent measurement, method partly reviewed. Used in matrix note 26.

DMDreview: Xiaomi S905X5M and spatial dithering¶

Source: video, identified as DMDreview's Xiaomi TV Box S (3rd generation) test; source record S63. Full audiovisual and measurement-method audit pending.
Reported setup: Xiaomi's S905X5M under CoreELEC, playing FEL_test_12bit_gray2.mkv; comparison with Kodi on stock Google TV. Exact versions and the capture chain are not established here.
Reported observation: low-order output bits reveal a fixed spatial grid/stripe pattern (0:37–1:40). Similar DV dithering is reported under stock firmware (1:41–1:56), where FEL reconstruction is not demonstrated. The report describes tested P5/P7/P8 paths and a different result for ordinary HDR.
Interpretation: the author attributes this to a likely 10-bit internal stage with spatial dithering in the 12-bit DV output. That is not direct proof of the chip's physical precision or an unfixable hardware limit.
Practical significance: the author's close-up versus normal-distance assessment (1:57–2:40) is not a controlled visibility test. Ordered and random dithering cannot be ranked universally without considering their implementation, noise, banding and temporal behaviour.
Scope: this result concerns the tested S905X5M setup. Other S905X5 variants, including the AM9 Pro's S905X5-J, need their own evidence. The introductory Apple TV/AetherEngine mention is not an Apple TV test.

Follow-up: obtain exact firmware/builds, source hashes and capture details; compare multiple consecutive frames, output modes and matching HDR/DV signals to locate the stage producing the pattern. Retest before calling the limitation silicon-wide. The new account describes S928X differently from the earlier Dune summary (simple 10-bit packing versus dithering); reconcile both videos and configurations before revising the Dune conclusion.

LibreELEC-Hades RC8: playback on Intel and AMD¶

Source: original video · source record S64. PRELIMINARY VIDEO REPORT: observations below are attributed to a secondary transcript; direct audiovisual review is pending.
Reported setup: Hades RC8 on Intel N150 and AMD Ryzen 7 5800H, booted from USB SSD storage (0:06–0:54). Exact build hashes, display models and sample hashes remain unverified.
Reported results: Saving Private Ryan and Alien: Romulus UHD rips worked with certain settings. Samples labelled Transformers and Tron: Legacy FEL fell back to HDR10 despite multiple settings combinations (1:23–4:06). One output-mode change produced no signal (1:52). The presenter reports the same playback outcomes on AMD, with less buggy behaviour (4:06).
Limits: this is a playback/compatibility report, not numerical reconstruction validation. Successful Dolby Vision output does not itself prove correct FEL composition. The presenter's preference for YCbCr over IPT is not established as a quality advantage. Reported projector/camera flicker must not be counted as player artifacts.
Build scope: the presenter says newer CroqueMr builds play the problematic clips (5:25), without an exact version here. This does not establish universal compatibility or a current Hades defect. The PC matrix row describes CroqueMr/CB1, not Hades RC8.

Follow-up: verify the original captions, on-screen results table, hardware and settings; identify releases and sample files; retest the reported failures on later builds. Do not infer Atmos, DTS:X or full 3D support from the video's title or a table whose individual results have not been reviewed.

HT2 Tweak: Kodi Hardware Matrix¶

Source: Google spreadsheet, last updated 4 November 2026 · HT2 Tweak on YouTube
Shows: an enthusiast's overview of about 25 players: HDR formats, Dolby Vision MEL/FEL, 3D, lossless audio passthrough and more, with build notes. Independent of the manufacturers.
Does not show: how each cell was tested, or with which firmware. The sheet says its ranking reflects consensus among Kodi, CoreELEC and AVS Forum users and invites corrections, so it is a register rather than a set of measurements. It has no Apple TV app or disc-player rows.
Evidence: community register. Used in matrix note 24.

The HDR Dissector (RESET_9999): clipping above the mastering level¶

Source: Ugoos review, 5:37–7:44 (1 February 2025) · first-hand forum reports on the MakeMKV forum, July 2022 and March 2025
Shows: on-screen labels report highlight clipping at the mastering-display level on "Oppo, X800m2, X700", and no clipping on Ugoos, Shield, Apple TV or the TV's own app. The 2022 forum report describes a much weaker scene-by-scene brightness response on the Sony X700/X800M2 with an LG C2 than with an LG C8.
Does not show: firmware, the TV used in the video, the capture method, or captured HDMI metadata. No fix has been documented.
Evidence: first-hand report. Details in the case study. HT2 Tweak's spreadsheet attributes this channel to RESET_9999. The author's newer FEL and CMv4.0 test pattern (2 November 2026) shows a film frame that changes brightness with the enhancement layer and explains why unmodified metadata darkens the picture without it (S55); it is a demonstration pattern, not a measurement of players.

Developer tests (not independent)¶

Developers' own measurements are useful but remain developer evidence: AetherEngine's on-device notes (Apple TV 4K, 2nd generation) and CroqueMr's Master Reference vs Standard comparison (AMD Ryzen 5 7430U). See AetherEngine and CB1.

Test files and tools¶

Test files let anyone check a setup at home without measuring equipment. This section collects files and tools others can use, and says what each one shows.

Available¶

The HDR Dissector: FEL and CMv4.0 test pattern. Shows a large yes or no for whether the player decodes the Profile 7 enhancement layer, and a frame from real film content that should become clearly brighter when it does. Further sections check Dolby Vision CMv4.0, letterbox handling, the per-shot brightness metadata and the colourist's trim controls. The video explains each section; the download link is in the video's pinned comment (S55).
Sound test for Dolby Atmos (Native IT). An app for iPhone, iPad and Apple TV from the maker of Native Player, with tones for each channel and spatial placement tests. Useful for checking that every speaker, including the heights, is connected and placed as configured. App Store · about the app. It is the developer's own tool, not an independent check of Native Player's renderer.

Wanted: links to test files¶

Links to useful test files are welcome, including Dolby Vision FEL/MEL and Dolby Atmos or DTS:X material. Prefer reliable, maintained sources with stable download pages, such as the creator’s website or an established project archive. Please suggest a link and explain what the file tests. Especially useful:

Dolby Vision Profile 7 FEL and MEL files with a visible, documented difference when the enhancement layer is used.
Profile 7 with the enhancement layer removed but the original metadata kept, next to the same clip with adapted metadata and as plain HDR10, to show the darkening problem.
Profile 8.1 conversions of the same clip, to compare with the original Profile 7.
12-bit gradient ramps, to compare 12-bit, dithered 10-bit and plain 10-bit output.
Dolby Atmos and DTS:X channel and object tests: channel identification, including height channels, and objects that move along known paths.
Lossless audio references: tracks with known decoded PCM, for checking that the output is bit-identical.

Include the creator or source, the format and what the file should demonstrate. A stable source page with version information is more useful than a temporary download link.

Wanted: test software and testers¶

DMDreview's comparison of LibreELEC on a PC, CoreELEC, a Dune and a disc player (above) relies on the author's own software, which unpacks the HDMI signal back into 12-bit values. If that software or similar tools become available, they will be linked here. People with capture equipment and experience with such measurements are just as welcome: the proposed tests need someone to run them. Tests with moving pictures would complement the still-image measurements available so far.

Wanted: Vero V measurements¶

The Vero V has decoded the Dolby Vision FEL enhancement layer since OSMC's May 2026 update, but its output precision is still unknown in the comparison: OSMC does not state it, and no external measurement is known. Owners' experiences are collected in OSMC's FEL testing thread; these are user reports, not measurements. A measurement like DMDreview's would close the gap, either by the author testing a Vero V or by someone else running the same kind of measurement, if the tool is shared. Please submit results or point to existing ones.

Playback accuracy and practical impact¶

These are the two questions the tests should answer: does the player reproduce the intended signal and source features correctly, and do any differences matter in viewing or listening? “Playback fidelity” is the umbrella term, not a single score.

A reference must be named and justified for each comparison: known decoded samples, a specified reconstruction process, or a documented renderer and speaker layout. A commercial player is not automatically ground truth. Numerical agreement, feature preservation and perceptual similarity are separate findings.

“Independent” means independent of the implementation being assessed, with relevant affiliations disclosed. A developer's own test is useful evidence but remains a developer test. Reviewing a text is not an independent playback experiment.

Proposed tests¶

All entries below are PROPOSED and unassigned. None has been carried out yet. These are starting briefs for contributors to refine, not validated protocols.

ID	Question	Starting experiment	Evidence still needed
T01	Does content-over-MDL clipping persist on a particular player/build?	Repeat the HDR Dissector case with known patterns; hold display and mode fixed, compare firmware versions	Exact models/builds, source hashes, incoming/outgoing metadata, qualified capture and before/after results
T02	Where do AetherEngine and CB1 reconstruction results differ?	Feed identical decoded BL/EL and RPU to pinned implementations; compare samples at corresponding intermediate stages	Executable harness, intermediate dumps, error maps, arithmetic/filter settings and a justified reference
T03	When is 10-bit dithering versus 12-bit output visible?	Match reconstruction and display mapping, vary quantisation only; combine sample analysis with randomised blind viewing	Verified HDMI paths, dither phase/temporal analysis, display conditions, trial results; avoid attributing whole-player differences solely to bit depth
T04	Which spatial information reaches the speakers?	Use known object trajectories and channel-identification material; compare bitstream and local rendering on a declared layout	Renderer/build details, gain/time alignment, channel captures and evidence distinguishing native rendering from upmixing
T05	Why do PCM and bitstream differ on a particular 2.1 system?	Align playback levels, document downmix/DRC/bass management, and compare before and after receiver processing	Synchronized captures, coefficients/settings where available, residuals and controlled listening; no assumed equality
T06	Which sources show a meaningful FEL contribution?	Use the same edition and controlled full-composition versus BL-based paths; document any metadata adaptation	Exact disc identifiers, timestamps, signal differences and controlled visibility tests; avoid treating every FEL title as equivalent

For T03, include grayscale and colour ramps at several PQ luminance levels, plus film scenes. Keep reconstruction, mapping, display mode, settings and viewing distance fixed, and verify that switching output depth has not also changed chroma format or HDR mode. Record consecutive frames to distinguish fixed spatial patterns from temporal dither. A colour meter can check average light levels but cannot alone establish pixel-level or temporal dither behaviour; camera recordings need documented exposure, sampling and processing. Combine measurements with randomised blind viewing, and report these as separate results. These are proposed controls, not a validated measurement protocol.

Start with Picture priorities and Sound priorities. A useful test should resolve a real uncertainty, not merely produce a larger number.

Proposed, reported and reviewed are different states¶

Status	Meaning
PROPOSED	A question and draft method; no result
IN PROGRESS	A named contributor is running a documented test
SUBMITTED	A result or external source has been supplied, but not reviewed
REVIEWED	A named reviewer checked the stated method and claim; limitations remain visible
REPLICATED	A separate contributor reproduced the bounded result; identify both setups
DISPUTED / SUPERSEDED	Conflicting evidence or a newer build changes the conclusion; retain the history

Submit a test or an existing source¶

You can contribute your own experiment or point to an existing YouTube video, technical report or research paper. Include the relevant timestamp, section or figure and explain precisely which question it answers. Label it as your result or someone else's; do not imply endorsement by linking it.

Record the test ID, date, tester, source edition/hash, app/firmware/commit, active mode, display/audio chain, reference and limitations, reproducible procedure, results and uncertainty. A screen recording or filmed TV must not be described as direct HDMI measurement. Negative and inconclusive results are useful too.

Use templates/test-report.md. Link to recordings and datasets on reliable, maintained source pages, with version information and checksums where available. Disclose relevant affiliations and preserve enough information for others to repeat the work.

Results register¶

No community submissions or independent replications have been registered yet. The existing external case study is a historical report with an explicit audit limit, not a completed local test.

When a result arrives, add a dated entry with: test ID · contributor · tested versions · result link · evidence status · reviewer · limitations. Connect the bounded finding to the affected article and player row. Do not replace an old result silently when firmware changes.

How to submit¶

Submit a pull request with the report and source links, or open an issue proposing a test. Review checks the method and scope before any capability claim changes.

Methods and reference cases · Evidence policy · Contribution workflow