Posts by cinemaONE

Quote from JdWijs

With 3D videos in MP4 it switches to full screen, that is good, but it switches the UI back to 2D again when stopping the video.

Thanks for testing. Two settings get closer to what you describe (Settings › Player › Videos, setting level "Advanced"):

• "Disable stereoscopic 3D mode when playback ended": switch it off and the UI stays in 3D after a video ends.
• "Playback mode of stereoscopic 3D videos": set it to "Preferred mode" so Kodi doesn't ask on every start.

3D for pictures doesn't exist in Kodi itself (LibreELEC ships Kodi unchanged here), so the place for that request is the Kodi forum's feature-request section or Kodi's GitHub.

Quote from JdWijs

Is it possible to make the Libreelec switsch to SBS 3D mode across the whole screen regardless extentions or EXIF information?

Welcome! For videos, Kodi treats a file as 3D when its name contains both a "3D" tag and an "SBS" tag, e.g. "clip.3D.SBS.mp4" (HSBS also works), or when the container marks it as 3D. For an untagged file, open the video settings during playback and set "Stereoscopic 3D mode of video" to side-by-side. The tags can also be changed with the stereoscopicregex3d / stereoscopicregexsbs entries in advancedsettings.xml.

Pictures are different: as far as I know, Kodi's picture viewer has no 3D handling, so SBS JPGs always show as one flat image. Converting them to a short SBS video named as above is a workaround.

Quote from Samui67

Could this working configuration help identify why frame packing is unavailable on the DisplayPort-based system?

Nice result, and it answers your question: the driver sees that module as HDMI-A-1, so the 3D modes are offered. On the other PC it sees DP-3, so they aren't. I was wrong to assume the module wouldn't help. HP lists the HDMI Flex IO card (3TK75AA) for the 705 G4 SFF too, so try moving your module across, if it's that part. If the log then shows HDMI-A, you have 3D. I can't promise it will, as I haven't seen this on the SFF.

If it doesn't work out, I'm happy to reconsider what I said earlier and make you a test build for the passive cable. It would be untested on my side, since I only have active adapters, so you'd be the test. Let me know how the module goes.

Quote from LNorden

Will it has LLDV as good as the UGOOS?

On LLDV: Hades' build has it (setting off by default, and it applies only when the display offers DV solely as Low-Latency). I tested RC4 on an RX 7600 against a Homatics R 4K Plus, through a VRROOM with an LLDV EDID, and both looked natural. The tone mapping is Hades' own rather than Dolby's, so it isn't identical: moderate colours matched a reference composition, saturated ones came out brighter. CroqueMr's build had no LLDV when I last tested it (RC2).

I haven't tried an H 255 (780M) or Plex, so I can't say anything about those or about bitrates.

Quote from Samui67

I was wondering whether extending the kernel patch to support DP-to-HDMI connections might be technically feasible.

Thanks for the offer, but I won't be writing this one. From reading the driver, only a passive DP++ dongle could work with a small generic change, because the GPU then sends a real HDMI signal. Active converters are blocked by the driver itself (only frame-alternate 3D is allowed, "bad infoframe translation"), and the 3D infoframe isn't sent on DP at all. A 4K DP-to-HDMI cable is often active, and both adapters I own are active, so I can't test the passive case. If CroqueMr wants to try it, the place to start is the HDMI-only stereo_allowed check.

Quote from Samui67

Kodi seems to recognize the 3D content but selects SBS instead of frame packing.

I checked your log: Kodi is on connector DP-3 and its mode list has no 3D modes (no 1920x2205 frame-packing line). On AMD the kernel patch behind 3D on these builds offers those modes only on real HDMI connectors, because DP-to-HDMI dongles rejected the 3D timings in link validation.

The "3D sbs (32)" is the same plain 1080p mode (32) as your 2D playback, with Kodi drawing both eyes side by side. No 3D signal reaches the projector, which is why you see two images. So the limit is the DP output, not Vega 11, and SBS or TAB files need the same 3D modes. We have only tested 3D on native HDMI.

Quote from CroqueMr

I can check that

In case it helps with the PGS up/down request: my xbmc#29060 already moves PGS with the existing subtitleshiftup and subtitleshiftdown actions (measured on my RX 7600).

popcornmix  NTM-3D The freeze after a seek in NTM-3D's log (#208048) might be a Kodi bug rather than the Pi kernel. I can reproduce the same sequence on x86 with Avatar: Fire and Ash: after the seek, DTS sync is lost, the next frame is taken as a stream with no type, the sink fails ("Unable to open the requested channel layout"), and Kodi then allocates memory until it is killed. On my 64 GB box that took about 20 seconds; a Pi would just freeze.

The cause is in CAEStreamParser::SyncDTS (an untyped DTS-HD frame gives a duration of 0, and CActiveAEBufferPool::Create() never finishes). Fix: https://github.com/xbmc/xbmc/pull/30218 (two small commits). With it, the same seek recovers as DTS-HD MA and memory stays flat.

popcornmix, if you pick it up for the RPi builds, NTM-3D could confirm whether the freeze is gone.

Prepared with Claude Code (Anthropic).

Round 42 is up: https://github.com/cinema-ONE/Lib…ound42-20261030

Changes since round 36:

• LibreELEC master of 2026-10-30 with Kodi 22 Piers and kernel 7.3.
• popcornmix's current 3D branch, including disc resume and the playlist chooser, and a fix of mine he merged: Blu-ray 3D subtitles keep their depth when the title moves to its next play item.
• A seek in a DTS-HD MA track with passthrough on no longer runs Kodi out of memory.
• DisplayPort monitors that also advertise HDMI get full range RGB.

I tested a full-length 3D Blu-ray ISO in frame packing, DTS-HD MA seeks with passthrough, and power-cycling the projector, on my NUC with an RX 7600.

Prepared with Claude Code (Anthropic).

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)