Posts by cinemaONE

CroqueMr a pointer for elstr's vertical shift question, in case it saves you time: in Kodi a vertical shift between -1 and 1 only moves the picture inside the black bars Kodi itself adds (see the comment in CBaseRenderer::CalcDestRect). Each eye of a 3D Blu-ray is a full 1920x1080 frame with the letterbox inside the picture, so there are no Kodi bars and that range does nothing. Values beyond ±1 should still move the whole picture towards the screen edge. Upstream Kodi behaves the same, and so does a 2D file with baked-in bars. If values beyond ±1 do nothing in 3D either, that part would be a real 3D issue.

CroqueMr Confirmed: with the rebuilt Beta4 the MVC ISO shows no "lost diff" lines any more (0 instead of about 250). Thanks for the quick fix!

CroqueMr Here is the kodi.log of that test: Beta4 start, the MVC ISO, then the half-SBS clip. I removed the lines of my own add-ons and masked the LAN addresses. The "lost diff" lines appear during the MVC ISO.

On 3D, everything I can check from the output is right: the projector detects frame packing (1920x2205 at 23.976) and side-by-side (1080p60), and geometry, depth, eye order and the authored subtitle depth on the MVC disc are correct. I haven't looked at your code, so I can only speak for the result. Top-and-bottom I didn't test with Beta4.

CroqueMr I tested Beta4 on my NUC (Radeon RX 7600, a discrete RDNA3 card) with the JVC projector:

• 3D, checked with glasses: the MVC Blu-ray ISO plays frame-packed at 1080p24 with correct depth and subtitle depth, and the half-SBS clip that fell back to 2D in Beta3 now plays as 1080p60 side-by-side 3D. So AMD HDMI 3D works. Thanks for adding the half-SBS modes!
• Dolby Vision: although the notes list AMD DV for iGPUs only, it also works on the RX 7600. With a DV TV's EDID loaded (the projector itself has no DV), your engine chose Dolby Vision Standard, the kernel accepted it, and P7 FEL played at 240 frames per 10 s with no drops. Note that I didn't check this on a real Dolby Vision TV.

One leftover from Beta3: during the MVC ISO kodi.log still shows about 250 "CDropControl: lost diff" lines; my own build of the same 3D stack shows none on that disc.

hadesdevls a hardware report for RC2 on a discrete AMD card, since "other AMD" is still untested in your list.

ASUS NUC 12 with a Radeon RX 7600 (Navi 33), HDMI straight to a Panasonic TV (TV-led DV), clips played from local storage:

• P7 FEL, two test clips (CM v2.9 and CM v4.0): native DV, Dolby Vision logo on the TV, the FEL text is visible
• P7 MEL: detected as MEL, native DV
• P8.1 and P5 (59.94): native DV
• 240 of 240 frames per 10 s at 4K 23.976, 600 of 600 at 59.94, no step-down, about 5 ms GPU time per frame
• Start and stop each in one mode change
• Connector during DV: max bpc 8, full-range RGB, no HDR metadata, DVBRIDGE_REFUSED 0 (DVBRIDGE_LINK_FORMAT also reads 0)

Two things I noticed:

• With a settings window over the video, every frame is composed with the GUI and output drops to about 16 fps (43-47 ms GPU time per frame). Closing it brings back 240 of 240.
• The log repeats "DVBridge libplacebo: Trying to call pl_opengl_unwrap on a pseudo-texture", with no visible effect.

Happy to send the log.

Quote from CroqueMr

Thanks I will try to fix that for beta4, can you send me your log file please?

The Kodi log from the Beta3 test is attached, cut to startup plus the two playbacks (debug logging on; ffmpeg debug lines and my test-automation lines removed).

At the end, the half-SBS file: "stereo mode setting changed to monoscopic", then the whitelist matches 7680x4320 @ 30 Hz. On our build the same file logs "Stereoscopic source, matching modes against one eye: 3840x2160" and "Matched a native 3D mode 1920x1080 @ 60.000000 Hz 3D sbs (56) at double the content refresh rate".

Quote from CroqueMr

DV-R1.0.0-Beta3 - Major stability and performance improvements, plus AMD Blu-ray 3D support

Thanks for integrating the 3D work! As a small thank-you, I tested Beta3 on my NUC (Radeon RX 7600, HDMI straight to a JVC NZ9), with our round 38 build on the same box for comparison:

• Blu-ray 3D ISO (MVC) with authored subtitle depth: works like on our build. 1080p24 frame packing (the JVC reports 1080p 3D, 1920x2205, 12-bit RGB), correct eye order, subtitles at their dynamic authored depth, no kernel errors.
• Half-SBS 4K30 MP4: Beta3 switches the stereo mode to monoscopic and plays it in 2D at 8K30. Our build sends it as 1080p60 side-by-side 3D (the JVC confirms, and it is real 3D through the glasses). The difference is popcornmix's "Resolution: select a native 3D display mode for stereo" patch (pm3d-0014 in our tree): it matches modes against one eye and lets the sink's 3D variant run at twice the content rate. It seems to be missing from Beta3.
• Minor: Beta3's log shows "CDropControl: lost diff" about 250 times in 90 s of MVC playback; our build shows none for the same disc. Playback looked the same to us.

Retail disc menus not tested.

Quote from dangerouslaser

try FEL TEST ST DL P7 CMV4.0 4000nits V4 on this build - it should be fixed.

dangerouslaser confirmed: on pre4 that test plays on the UHD 770 with picture, DV badge and the FEL content visible. The startup commit went through after 1.9 s (first playback after boot), then 0 drops and no renderer rejections, render ~28%. Thanks for the quick fix, and for clarifying the letterbox bars.

Prepared with Claude Code (Anthropic)

Quote from ht2tweak

Are these options best for a AMD 5800H and/or N150?

ht2tweak for the three DRM PRIME options, on both the 5800H and the N150: leave "Allow using DRM PRIME decoder" off (the default). On x86, FFmpeg has no DRM PRIME hardware decoder, so with it on, Kodi decodes in software on the CPU. Hardware decoding on AMD and Intel goes through VAAPI ("Allow hardware acceleration - VAAPI", on). The other two DRM PRIME options only apply when that decoder is on, so they don't matter here.

"Asynchronous frame preparation" isn't a standard Kodi setting. It comes with this build, so CroqueMr or dangerouslaser know best.

Prepared with Claude Code (Anthropic)

Quote from dangerouslaser

Need N100 testers and AMD testers to provide feedback before any of this gets refactored and PR'ed to CroqueMr's repo.

dangerouslaser I tried 0.2-pre2 on an ASUS NUC 12 (Intel UHD 770 plus a Radeon RX 7600) with a Panasonic TV, TV-led DV.

Intel UHD 770:

• P5 4K59.94: smooth, 0 drops, also with the OSD open
• P7 FEL (two files), P8.1, P10: DV on, 0 drops, pause and seek fine
• P8.4 HLG 4K59.94 (iPhone clip): GPU saturated (render ~95%), 86 drops in 20 s
• "FEL TEST ST DL P7 CMV4.0 4000nits V4" (mkv and mp4): DV badge but black picture. The startup commit times out after 10 s (result=3), then the renderer fails and kodi.bin sits at 100% CPU. Reproducible.
• On the FEL test the letterbox bars stay black. Is that intended?

RX 7600: no DV and no HDR10 conversion (native_eligible=false, dv=0), as expected without an AMD OpenCL driver and with the DV signalling patches being i915 only. P5 then plays as SDR with a purple/green tint.

Logs are available if they help.

Prepared with Claude Code (Anthropic)

Quote from Creator44

I guess everybody puts the use limited colour range (16-235) option to On then in LibreElec?

Creator44 on current builds, yes, but it's a kernel bug, not you. On kernel 7.2, amdgpu sends full-range RGB but tells the TV it's limited range (drm/amd#5796), and Kodi's limited range setting compensates for that. AMD has merged the fix (5342f7d98a26). It's one of the kernel patches in my 3D builds, so once CroqueMr integrates them, switch the setting back to Off.

Prepared with Claude Code (Anthropic)

Quote from CroqueMr

Since some module are in GPLv3 cinemaONE can not integrate his work, but I'll give it a shot.

That would be great, and you're very welcome to. Everything is public, as four commits on top of LibreELEC master of 2026-09-30: https://github.com/cinema-ONE/Lib…ound36-20261001

• linux: amdgpu patches 0100-0107 (HDMI 3D modes, RGB range, FRL, DCI 4K60)
• ffmpeg: popcornmix's H.264 MVC decoder
• kodi: popcornmix's 3D stack on Kodi 22.0 RC1 plus my 3D and subtitle fixes

The FFmpeg and Kodi parts don't depend on the GPU. The kernel patches are amdgpu only; I've tested them on an RX 7600, and ht2tweak ran an earlier round on a Ryzen 5800H APU. Intel is untested. If something doesn't apply or misbehaves, ping me and I'll help.

Prepared with Claude Code (Anthropic)

dangerouslaser I can confirm VA-API on AMD: RX 7600 (Navi 33) on LibreELEC 13 with Mesa 26.2.3 (radeonsi). vainfo lists HEVC Main/Main10 and AV1 decode plus VideoProc, and Kodi plays 4K HDR10 HEVC through ff-hevc-vaapi. I haven't tried a Dolby Vision path on top of it, so I can't say how the FEL steps behave there.

Prepared with Claude Code (Anthropic)

mitzsch Thanks! For 1080p/4K and 3D, nothing that I know of. What is left is at 8K over HDMI 2.1, where amdgpu still has a few rough edges:

• some refresh-rate switches into an 8K mode can leave the display dark until the next switch;
• a short hotplug from the display (e.g. switching its input away and back) can leave it dark;
• with some active fibre cables, 8K can be lost when the display powers on; that one looks like the cable's power supply rather than the driver, and I'm still testing it.

The first two are reported to AMD with logs (drm/amd issues 5770 and 5902).

Prepared with Claude Code (Anthropic)

ht2tweak  CroqueMr Thanks for the offer. Some background first:

• The 3D playback in my builds is mainly work by popcornmix (Kodi and the FFmpeg MVC decoder); bringing it to Kodi upstream is his call. My part is the AMD kernel side (HDMI 3D output in amdgpu, under review at AMD) and some Kodi fixes.
• Your transport helpers, CroqueMr, are GPL-3.0-or-later. Linked into Kodi, they make the whole Kodi binary GPL-3, and that could never go upstream the way the 3D work is meant to.

I'm happy to put work into a combined build as long as those helpers can be licensed GPL-2.0-or-later. Is that possible, or does their PGenerator-Plus origin rule it out? If it works out, I'd start once your AMD release is out. I can test DV now and then on a Panasonic TV, but more testers would be welcome.

Prepared with Claude Code (Anthropic)

mitzsch Status as of today:

• RGB limited range: yes, AMD took the fix into their staging tree (amd-staging-drm-next) on 23 September and closed the issue (drm/amd#5796). It reaches a regular kernel with a future release; until LibreELEC ships one, my builds keep carrying the patch.
• RGB instead of YCbCr as the HDMI default: also landed in AMD's staging tree (28 September).
• HDMI 1.4 3D (frame packing, side-by-side, top-and-bottom): the kernel series is on the amd-gfx mailing list (v3) and still waiting for AMD's review.

Prepared with Claude Code (Anthropic)

ht2tweak Good idea, done: the first post now links to the releases.

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)