Posts by cinemaONE

Round 36 is up: https://github.com/cinema-ONE/Lib…ound36-20261001

Changes since round 21:

• LibreELEC master of 2026-09-30 with Kodi 22.0 RC1 and kernel 7.2.8.
• popcornmix's current 3D branch, with two fixes of mine he merged: in MakeMKV remuxes, subtitle depth now follows the offset sequence each track's 3d-plane tag names, starting at the right frame.
• A reconnected 8K display gets FRL back instead of falling to TMDS, and 4096x2160 at 60 Hz keeps its own timing.
• Rounds 20 and 21 wrote a debug log, /storage/kodi-atomic.log, with two disk syncs per video frame. This round drops it. If you ran those rounds, please delete the file.

I tested MVC MKVs, SBS and TAB files, a 3D Blu-ray ISO, 4K HDR10, Dolby Vision (HDR10 base), and TrueHD Atmos and DTS-HD passthrough on my NUC with an RX 7600. Note that Kodi 22 asks which playlist to play on a Blu-ray with no title of 30 minutes or more, such as most 3D sample ISOs.

Prepared with Claude Code (Anthropic).

Quote from RalMun

My guess is that the stock FFmpeg drops the dependent view, and that your MVC-capable FFmpeg is what's missing in my build. Where do I find that FFmpeg source or patch set (repo/branch or patch files) that goes with the Kodi tree, so I can use it in tools/depends/target/ffmpeg instead of the stock tarball?

Hi RalMun, I build popcornmix's branch for my x86 LibreELEC images, so here is what I know.

Your guess is right: stock FFmpeg decodes only the base view, so an MVC title plays as 2D. popcornmix's H.264 MVC decoder is in his own FFmpeg fork, https://github.com/popcornmix/FFmpeg, on two branches:

• mvc_work: Raspberry Pi FFmpeg 8.1 plus the MVC commits. That is the closest match to your 8.1.2 base.
• dev/mvc/h264_mvc_1: the same MVC commits on upstream FFmpeg 8.0.

I applied the MVC commits from dev/mvc/h264_mvc_1 to FFmpeg 9.0 without conflicts. With them, Kodi pairs both views and MVC remuxes play in 3D.

Prepared with Claude Code (Anthropic)

Quote from mitzsch

so with kernel 7.3(rc), ycbcr is the default again?

Yes, 7.3-rc tries YCbCr 4:4:4 first again, so your RX 6600 would be back on YCbCr there. A patch that makes amdgpu try RGB first, as the new Color Format property documents, is reviewed but not merged yet, so that may still change.

Quote from mitzsch

So until your patch gets merged, "we" can fix it (on "upstream" le13 nightly) ourselves by setting the Broadcast RGB setting to limited.

And yes, on 7.2 setting Broadcast RGB to Limited 16:235 is a clean workaround until the fix lands. Just keep Kodi's "Use limited colour range" off with it.

Written with Claude Code (Anthropic).

Quote from mitzsch

how does the "internal RGB full" processing affect YCbCr output (which, as far as I understand, is limited color range in its nature?)

What I don't understand, would have setting the "Broadcast RGB" parameter to limited via autostart.sh and kmstest in the first place would fix the issue, or would the kernel still internally work with RGB full and a fix to the kernel is inevitable?

Linux 7.3 introduces a DRM "Color Format" property with AMD GPU driver support; does this affect the situation?, Is your fix still needed there or is this a completely different topic?

I won't claim I understand all of this fully; I'm just pushing Claude to get to the bottom of it. Here are your answers:

(1) YCbCr output is not affected. Broadcast RGB, and the choice my patch changes, only apply to RGB output. For YCbCr amdgpu always converts to limited range and the InfoFrame says YCbCr, so pixels and tag agree.

That you get YCbCr 4:4:4 is interesting: current LE13 nightlies ship kernel 7.2.3, where amdgpu sends RGB by default. What does uname -r say, and how old is your nightly?

(2) Yes. With Broadcast RGB at Limited 16:235 the kernel compresses to 16-235 itself and the InfoFrame says limited, so the signal is consistent without any patch. Kodi holds DRM master, so set it before Kodi starts, as you suggest, and leave Kodi's "Use limited colour range" off, or the range is compressed twice. The patch only makes Automatic, the default, do this on TV modes.

(3) Different topic. Color Format picks the encoding (RGB, YCbCr 4:4:4, 4:2:2, 4:2:0), not the range. Whenever the result is RGB, the fix is still needed. 7.3-rc tries YCbCr 4:4:4 first, which hides it by default, although the property's documented default is RGB.

Quote from vobs

May be a minor thing: I have lots of full side-by-side files with names like 'Movie.Year.3D.FSBS.mkv', but Kodi doesn't recognise them as 3D movies. I would have to rename them like 'Movie.Year.3D.SBS.mkv' – it seems that the letter 'F' is preventing the 3D recognition.

That one can be fixed without renaming. Kodi detects 3D from the file name with three patterns, and the side-by-side pattern only accepts "sbs" with an optional "h" in front, so "SBS" and "HSBS" match but "FSBS" does not (the same goes for "FTAB"). The patterns can be overridden in /storage/.kodi/userdata/advancedsettings.xml:

<advancedsettings>
  <video>
    <stereoscopicregexsbs>[-. _][fh]?sbs[-. _]</stereoscopicregexsbs>
    <stereoscopicregextab>[-. _][fh]?tab[-. _]</stereoscopicregextab>
  </video>
</advancedsettings>

If the file already exists, put the two lines inside its existing <video> section instead. Restart Kodi afterwards. The name still needs the "3D" part as well, which yours have.

Prepared with Claude Code (Anthropic)

Over IP. The VRROOM has a web interface on the local network, and Claude Code used it directly: it read the status page (the same values the web UI shows) and switched the active input through the HTTP command interface. That way it could flip between the NUC and a CoreELEC box and read each signal without anyone touching the device. The picture comparison itself I did by eye.

Its readout is not perfect, though. The bit depth has been wrong more than once: it has shown 8-bit on streams that the projector's own info menu or the kernel reported as 12-bit. And a 3D flag such as "3D-FP" can stay on the status line after playback has already gone back to a 2D mode. The range tag held up in this case, since the picture and the kernel fix both confirmed it, but I cross-check the other fields with the projector's info menu.

If you try a grabber, check that it reports the AVI InfoFrame and not just the pixels. Many capture devices decode the stream without showing the quantization bits, and some convert the range on capture, which would hide exactly this mismatch.

Prepared with Claude Code (Anthropic)

"HDMI analyser" is a term Claude Code introduced when writing up the measurement. It is not wrong, but the device is simply an HDFury VRROOM, an HDMI switch that sits between the NUC and the projector. Its status page shows what arrives on each input, read from the signal itself, including the AVI InfoFrame the source sends. That is where "RGB L 12b" comes from: RGB, tagged limited range, 12-bit. Nothing on the NUC reports this, which is what made it useful here: it shows what the driver actually signals, independent of what Kodi or the kernel believe they are sending.

Many TVs and projectors have an info or signal menu that shows similar information for the current input: resolution, refresh rate, RGB or YCbCr, bit depth, and on some models the detected range as well. Worth a look there first.

Without either, you can still spot the mismatch by eye. Play a black-level test pattern (a PLUGE or "black clipping" clip): on an affected setup the bars just above black vanish with Kodi's "Use limited colour range" off and come back with it on. Round 21 fixes the mismatch in the kernel, so there the pattern should look right with that setting left off.

Prepared with Claude Code (Anthropic)

On the range question: what I can say with numbers is that the AMD box now sends a consistent signal (pixels and infoframe agree) and that on the same paused frame it matches an Amlogic box by eye. Whether that is "on par with a Pi 5" I cannot measure, there is no Pi here. The Zidoo result is vobs's, not mine, but it is the same class of fix: RGB with a range the display expects.

Since this evening the box also runs a kernel carrying the fix itself (patch on amd-gfx, drm/amd issue 5796): with Kodi back at its default full-range setting, the NUC and the Amlogic box show the same picture on that frame. So the Kodi setting is only needed on kernels without the fix; a round 21 image with it will follow.

On Bluetooth: the build has it and it is on by default (my NUC never had it enabled by hand and lists its adapter), so "No Bluetooth adapter found" means the adapter itself is not coming up, and I need to know which chip it is. Over SSH:

lsusb

dmesg | grep -iE "bluetooth|hci0|firmware"

bluetoothctl list

and post the output (pastekodi works). The kernel has the Bluetooth core and the USB HCI driver, and the firmware for the MediaTek combo chips the SER5 usually ships with (MT7921/MT7922) is in the image, as is the Intel and Realtek one; the dmesg lines show whether the adapter was found and which firmware it asked for.

Round 21 is up: https://github.com/cinema-ONE/Lib…ound21-20260910

It is round 20 plus the amdgpu RGB range fix from the previous posts (kernel patch, upstream drm/amd 5796). On this image leave Kodi's "Use limited colour range (16-235)" at its default (off); the round 20 workaround would compress twice here. Verified on the NUC against an Amlogic box on the same frame; a report from a Ryzen/Vega box would be welcome.

Prepared with Claude Code (Anthropic).

Follow-up on "punchier": I now have a measured cause for a brightness difference on AMD, and it is neither the scaler nor the projector. I compared the NUC and an Amlogic box on the same paused 3D frame: same highlights, but the NUC's shadows and mid-tones were clearly darker (photos at identical exposure: median luma 4 vs 26).

On the wire the NUC sends RGB 12-bit and the HDMI analyser reports it as limited range. In the amdgpu source the output colour space for RGB stays full range unless the "Broadcast RGB" connector property is explicitly set to Limited (Automatic is treated as full), and the AVI infoframe only says "full" when a sink-capability bit (qs_bit) is set, which nothing in amdgpu_dm ever sets. Result: full-range pixels tagged as limited. A display that honours the tag expands 16-235 to 0-255, so everything below 16 turns black and the mids go dark. That is the "crushed" look, and next to it any device with a consistent signal looks brighter and punchier.

Workaround in Kodi, no rebuild: Settings > System > Display > "Use limited colour range (16-235)" = ON. The default is OFF. Kodi then renders the 16-235 levels the tag promises, and the NUC and the Amlogic box now look the same on that frame. It only takes effect for playback started after the change.

This applies to any Kodi on amdgpu over HDMI with the default setting, not only to these 3D builds. I will probably report it to the amdgpu developers.

Prepared with Claude Code (Anthropic).

Good to know, and it narrows things down. The measurement says Kodi on AMD hands the display driver a frame identical to the decoded source, so for full-res content the difference you and vobs see has to come after that point: what goes out on the wire, or what the projector does with it. Two candidates, both measurable without eyes:

(1) Link format. The Pi normally sends 8-bit RGB in frame packing; the AMD box can be on 10 or 12-bit, or YCbCr, and a projector may process those differently. If you have an HDMI analyser or your projector shows an input info page, the format, bit depth and colour space for each source would settle this.

(2) Chroma reconstruction. The source is 4:2:0. On AMD, Kodi's GL shader rebuilds the chroma with bilinear sampling before the frame reaches the wire; on the Pi the HVS does it in hardware. That changes colour edges only, never luma edges. I can measure the AMD side with a coloured pattern.

So one question back: is the Pi sharper on a pure luma pattern (the black and white line blocks of "3D MVC Resolution Pattern"), or only on coloured content? That alone separates 1 from 2.

Prepared with Claude Code (Anthropic).

ht2tweak, I measured the sharpness question on the NUC (RX 7600, round 20) instead of judging by eye: Kodi screenshot of one eye in the frame-packed mode, compared pixel for pixel with the source frame of the "3D FSBS Resolution Pattern" test clip, and with half-SBS/half-TAB versions of the same pattern.

Full-resolution content (MVC, full SBS, full TAB) is pixel-exact on AMD: no shift, no resampling, every line-pair block identical to the source. So for a Blu-ray MVC rip there is nothing to sharpen on the Kodi side.

Half SBS and half TAB are a different story. Each eye is upscaled 2x, and on AMD that upscale is plain bilinear no matter what "Video scaling method" you pick. Lanczos3 and spline36 are silently ignored (kodi.log says "chosen scaling method 9, is not supported by renderer"). The reason is a Kodi bug, not a driver limit: the "HQ scalers for scaling above 20 %" check looks at the whole 1920-wide frame going to a 1920-wide eye viewport and concludes 0 % scaling, while the eye is really stretched from 960 to 1920. That check is in upstream Kodi's GL and GLES renderers, so it affects every x86 build, not just this one.

Workaround until it is fixed: set Video scaling method to Lanczos3 (or spline36) AND set "Enable HQ scalers for scaling above" to 0 %. Both are needed. With that, the finest lines the half-res pattern can still carry come out at 67 of 255 contrast instead of 47, which is what a proper Lanczos upscale gives.

The Pi does not go through Kodi's GL scaler at all: the video plane is cropped per eye and the HVS scales it in hardware, with a multi-tap filter. AMD cannot use that path for software-decoded MVC (its planes only take NV12/P010, see xbmc issue 29160), so it lands on the GL path. That explains a Pi > AMD difference on half-res material, and predicts none on full-res. I have not measured the Pi myself.

Maybe I will send a fix to Kodi upstream.

Prepared with Claude Code (Anthropic).

Thanks ht2tweak for your testing, feedback and screenshots. Maybe I'll have another look about the picture sharpness, could be I missed some settings.

Until recently, I thought 3D MVC wasn't even possible anymore on HDMI 2.1 GPUs / hdmitx21, but then I saw the work being done on the AM9 Pro (over in CoreELEC) and here for the Raspberry Pi. So I pushed Claude to look into a solution for x86/amdgpu, (and I helped with the testing at least). It's nice to contribute a small piece to our little 3D renaissance .

Yes, Kodi uses DCC. Its GBM window system lets mesa pick the framebuffer modifiers, and on RDNA3 that means DCC-compressed buffers by default. With only the kernel patches, the first flip after switching into a frame-packed mode never completes and the display pipe wedges, that is the limitation in the cover letter.

The build here does not hit it because the Kodi stack carries a small patch of mine on top of popcornmix's branch (pm3d-0014 in the LibreELEC tree, "gbm: drop DCC modifiers from the output surface in a hardware 3D mode"): whenever the DRM mode carries a 3D flag, the DCC modifiers are filtered out of the plane's format list, so Kodi allocates uncompressed buffers for 3D and keeps DCC otherwise. So no limitation in practice with this image, but a stock Kodi on the patched kernel would wedge on the first frame-packed flip.

The proper fix belongs in the kernel: DC should either reject a DCC framebuffer on a stereo timing or handle it. That is the separate report mentioned, still to be written once I understand why the flip never completes. Whether older DCN generations are affected I cannot say; ht2tweak's SER5 ran the same Kodi patch, so his result does not tell.

Prepared with Claude Code (Anthropic).

Thanks for trying it, that is the first report from a different AMD GPU (Vega, DCN 2.1), so the kernel side is not RX 7600 specific. Good to know.

The stuttering has a likely cause. MVC is decoded in software, and on this build Kodi's default "PRIME render method" hands such frames straight to a display plane, which on amdgpu does not take the software decoder's pixel format; on my box that path stalled outright until I changed Settings > Player > Videos > "PRIME Render Method" from "Direct To Plane" to "EGL" (settings level Advanced or higher). Please try that first. The upstream issue is xbmc/xbmc#29160. If it still stutters, a debug log would show whether the GPU driver loaded and where the time goes: enable debug logging (Settings > System > Logging), play one clip, then run pastekodi over SSH and post the link it prints. The USB stick can make the GUI feel slow as well, but it should not affect playback once a clip runs.

On the thread question I agree, x86/amdgpu does not belong in popcornmix's Raspberry Pi thread. I have opened a separate one, 3D on x86 LibreELEC with AMD graphics (test builds) - it becomes visible once a moderator has approved it, let us continue there.

Prepared with Claude Code (Anthropic).

This thread is for native HDMI 3D (frame packing, top-and-bottom, side-by-side, MVC Blu-ray and remuxes) on x86 LibreELEC with AMD graphics. It grew out of popcornmix's Raspberry Pi thread (3D Support builds for Raspberry Pi); please keep Pi questions there.

What it is: LibreELEC Generic x86_64 built from LibreELEC master with kernel 7.2.4 plus five amdgpu/drm patches (HDMI 1.4 3D modes on HDMI connectors, the 3D layout announced in the HDMI InfoFrame, frame packing with the doubled timing), popcornmix's Kodi branch fix-stereoscopic-3d-gbm-upstream on top of Kodi 22 beta 2 (MVC playback, 3D Blu-ray ISO, authored subtitle depth including MKV remuxes) and his MVC-capable ffmpeg. The kernel patches are on the amd-gfx list as a three-patch series: https://lore.kernel.org/amd-gfx/202609…[email protected]/ - the Kodi work is popcornmix's and will go upstream after the Piers release.

Download: https://github.com/cinema-ONE/Lib…ound20-20260908 (img.gz for a USB stick, tar for updating an existing LibreELEC, sha256 alongside). Source branch local/frl-72y-3d in the same repository. This is a development build made for one machine, expect rough edges.

Tested: Radeon RX 7600 (RDNA3, DCN 3.2.1) on an Intel NUC through an HDFury VRROOM to a JVC DLA-RS4100, frame packing, TAB and SBS at 1080p24 in 12-bit RGB, MVC playback and authored subtitle depth from ISO and MKV. Reported working by ht2tweak on a Beelink SER5 (Ryzen 7 5800H, integrated Vega, DCN 2.1), all 3D formats.

Requirements: a native HDMI output on the GPU, the connector must show up as card0-HDMI-A-* in /sys/class/drm; a DisplayPort-to-HDMI converter does not work because the 3D signalling is HDMI only. Software decoding of MVC needs a reasonably fast CPU (a 5800H is plenty).

Settings after first boot: Whitelist (Settings > System > Display) with your 2D modes plus the 1080p24 3D entries, e.g. 0192001080024.00000ptabfrp, 0192001080023.97608ptabfrp, 0192001080024.00000ptab, 0192001080023.97608ptab (the 23.976 identifier must read exactly as your box offers it). "Adjust display refresh rate" on start/stop. "PRIME Render Method" (Settings > Player > Videos, Advanced level) set to EGL, because software decoded MVC frames cannot go straight to a display plane on amdgpu (xbmc/xbmc#29160). Frame packing is chosen by default; KODI_3D_PREFER=tab or sbs in Kodi's environment or stereoscopicpreferframepacking false in advancedsettings.xml changes that.

When reporting, please include the GPU, how the display is connected (direct, AVR, HDFury, splitter), what the display's info panel shows during playback, and a debug log (enable debug logging, play one clip, run pastekodi over SSH and post the link).

Prepared with Claude Code (Anthropic).

There is no official build with it, as popcornmix says. What I run is a LibreELEC Generic x86_64 development image built from the branch linked above: LibreELEC master plus kernel 7.2.4 with the 3D patches, popcornmix's Kodi branch and his MVC-capable ffmpeg. I have put today's image up here: https://github.com/cinema-ONE/Lib…ound20-20260908 - the .img.gz boots from a USB stick like any LibreELEC Generic image. It is a development build made for one machine, so expect rough edges; the release notes list what is in it and the two settings that matter (the 1080p24 3D whitelist entries and "Adjust display refresh rate" on start/stop).

Prepared with Claude Code (Anthropic).

In principle yes. The kernel changes sit in the shared amdgpu display-manager code (mode acceptance, the HDMI VSIF InfoFrame, stream sizing), nothing in them is specific to the RX 7600, and the MVC decoding is done in software by popcornmix's ffmpeg decoder, which a 5800H handles easily at 1080p.

Two caveats. I have only tested the RX 7600 on a 7.2 kernel, so an integrated Vega (DCN 2.1) is untested. And the patch enables 3D only on native HDMI connectors: if the SER5 routes its HDMI port through a DisplayPort-to-HDMI converter chip, as some mini PCs do, the kernel sees a DP connector and nothing happens. Check with ls /sys/class/drm/, the port you use must show up as card0-HDMI-A-1 rather than card0-DP-1.

Prepared with Claude Code (Anthropic).

The series is on the amd-gfx list, v3 as of this afternoon: https://lore.kernel.org/amd-gfx/202609…[email protected]/

Patch 1 lets DC accept HDMI 1.4 3D modes on HDMI connectors and announces the layout in the HDMI VSIF, patch 2 sends the 3D_Ext_Data byte for top-and-bottom, patch 3 sizes the frame-packed stream by the doubled timing. They are against amd-staging-drm-next.

The LibreELEC branch I run is here, with the same changes as patches against the 7.2 kernel plus popcornmix's Kodi stack: https://github.com/cinema-ONE/Lib…patches/default (0100 to 0104; 0101 additionally adds half side-by-side 1080p modes to the EDID parser, which is not part of the series).

Prepared with Claude Code (Anthropic).