Posts by cinemaONE

Correction to the note above: forcing top-and-bottom or side-by-side output does not need the environment knob. popcornmix's branch has stereoscopicpreferframepacking in advancedsettings.xml (<video><stereoscopicpreferframepacking>false</stereoscopicpreferframepacking></video>), which makes the half modes win the selection; alternatively, with "Adjust display refresh rate" off, a TAB or SBS mode picked by hand in the resolution setting stays put. Thanks to popcornmix for the pointer.

Posted on behalf of the box's owner; text prepared with Claude Code (Anthropic).

Native HDMI 3D now works on amdgpu too, with popcornmix's Kodi branch unchanged.

Box: LibreELEC (Generic x86_64, kernel 7.2.3) on a NUC with a Radeon RX 7600, HDFury VRROOM, JVC DLA-RS4100. Frame packing, top-and-bottom and side-by-side at 1080p24, RGB 12-bit, all engage the projector's 3D mode with correct per-eye geometry; MVC remuxes and 3D ISOs play through popcornmix's patches (his ffmpeg MVC decoder included), subtitles at the authored depth on both. The GUI runs at 8K60 over FRL with DSC on the same connector.

Kodi needed nothing beyond popcornmix's branch. amdgpu needed three kernel changes, now prepared as a series for amd-gfx: expose the HDMI 1.4 3D modes on HDMI connectors and scan them out as 2D with only the vendor infoframe announcing the layout (any DC stereo timing format makes the hardware treat the surface as two views), send the 3D_Ext_Data byte for top-and-bottom (the JVC ignores the 5-byte frame), and size frame-packed streams by the doubled 2205-line timing. Two unrelated FRL defects found on the way are filed as drm/amd issues 5770 and 5771.

One small Kodi-side addition went to popcornmix as a PR (https://github.com/popcornmix/xbmc/pull/30): authored subtitle depth for MVC remuxes (his store is fed from the Blu-ray input stream only).

A note for anyone testing TAB or SBS on a display that also offers frame packing: the current mode selection always takes frame packing, whatever "Preferred mode" says; KODI_3D_PREFER=tab|sbs in Kodi's environment is the way to force the other layouts.

Posted on behalf of the box's owner; text prepared with Claude Code (Anthropic).

Thanks - that answers it, and yours is the one that should go upstream. Ours is superseded.

One thing I could still usefully add: a cross-check on real material. I compiled your BlurayOffsetMetadata.cpp verbatim and our parser (which was derived from discs, not the spec) side by side, and fed both the same NAL chunks from 1 GB of Alita's dependent-view stream, about 20% into the feature.

253 OFMD messages found by each, 253 by both, 253 identical sequences x frames tables, 0 mismatches. 32 sequences, 12 of them dynamic, values 0..10 - which is also what an independent survey of that disc reports.

As a control I reverted ours to an old off-by-one layout (values read from byte 15 instead of 14): the same run then reports 253 of 253 mismatched. So the agreement is not a harness that cannot fail.

Two independent implementations agreeing byte for byte on real discs is probably worth more than either alone. Happy to send the harness or the ES slice if you want to reproduce it.

Discs where the effect is easy to see, from the survey: King Arthur: Legend of the Sword (22 of 32 sequences move, -1..37), Kong: Skull Island (24 of 32, -1..30), Jaws 3-D (19 of 32, -6..31). The negatives are worth testing separately - a disc with only positive values cannot catch a sign error.

(Disclosure as before: written with Claude Code, posted from my account.)

One more on the depth parsing, since there are now three implementations of this and they each have a different half of it.

Your branch (popcornmix/xbmc, fix-stereoscopic-3d-gbm-upstream) was last pushed 22 Aug and I cannot find the parsing in it, so I have no idea whether any of the below duplicates what you already wrote - please just say if it does.

There are two independent pieces to "1 plane + offset", and it is worth being explicit about them because they are easy to conflate:

1. The per-frame values, in an OFMD SEI in the dependent view - a UUID-tagged user_data_unregistered message carrying up to 32 offset sequences, one signed value per frame.

2. Which of those sequences a given PG stream uses - ss_offset_sequence_id in the MPLS STN-SS extension. Note this is a sequence index (0..31), not a depth; the depth is the per-frame value inside the sequence it names.

For (1) I have a parser that is a pure function - signature is (const uint8_t* data, size_t size, int nalLengthSize, vector<vector<int8_t>>& table), no platform headers, no syscalls, handles Annex-B and length-prefixed NALs, and unescapes emulation-prevention bytes before reading the table (skipping that shifts the values silently rather than failing). It is verified off-hardware by extracting it from the source at build time and running it over real dependent-view elementary streams: 80 messages / 32 sequences on one title matching a Python reference exactly, and 12 of 32 dynamic sequences on another, matching an independent survey of the same disc. About 120 lines. Yours for the taking if you have not already written it.

For (2), upstream libbluray does not expose ss_offset_sequence_id at all. boeschy has patched libbluray for it in his CoreELEC 3D fork (boeschy/xbmc-ce22), which as far as I can tell is the only open-source code that reads it - so that is probably the shortest path rather than either of us redoing it.

What I have that is not portable is the wiring: I get at the dependent-view NALs through the Amlogic codec, which is no use to you. Your DVDDemuxBluray3D and the MVC second-view work look like the natural place for it instead.

Happy to hand over the parser, the format notes, or the 151-title survey data in whatever form is useful - or to leave it alone if you have this covered already.

(Disclosure as before: written with Claude Code, posted from my account.)

Both of those are measurable, so here is what I have.

Dual bitmap stereoscopic subs: real, but rare. I read the STN-SS extension out of every playlist on 53 3D discs. Exactly one carries an SS-PG stream - Avatar (2009), playlists 00804.mpls and 00854.mpls, nine PG streams each with the ninth flagged SS-PG. On those playlists every ss_offset_sequence_id is 0xFF (none), so that disc uses a genuine stereoscopic PG instead of plane offset rather than alongside it. All 52 others are single-bitmap-plus-offset, which matches what you found.

Titles where the depth is easy to see. From the 151-title survey, sorted by how far the offsets travel - "span" is max minus min in px on a 1920 plane, "dyn" is how many of the 32 sequences change at all:

King Arthur: Legend of the Sword - dyn 22/32, -1..37 (span 38)

Kong: Skull Island - dyn 24/32, -1..30 (span 31)

Jaws 3-D (1983) - dyn 19/32, -6..31 (span 37)

Creature from the Black Lagoon (1954) - dyn 17/32, 1..37 (span 36)

Spider-Man: Homecoming - dyn 5/32, -3..39 (span 42)

The first four are the ones I would test with: a lot of sequences move and they travel a long way, so "working" and "not working" look obviously different. Spider-Man has the widest single span but only five sequences move, so most of its subtitles sit still - which is probably the kind of disc that made it look subtle.

Worth testing the sign separately from the magnitude: Jaws and Kong both go negative (-6 and -1), so they put subtitles behind the screen plane as well as in front of it. A disc whose values are all positive will not catch a sign error.

(Disclosure as before: survey and parsing done with Claude Code, posted from my account.)

popcornmix - answering your #72 (a sample with varying subtitle depth), since that looks like where this stalled.

You may not need a sample file at all. The offsets sit in an SEI in the dependent view, so they can be read straight off a disc without decoding anything. I have a small python tool that does it - nothing but python3 - and I ran it over 151 3D titles: all 151 carry the metadata, and 139 (92%) author depth that actually changes. Offsets reach 40 px on a 1920-wide plane.

For the titles NTM-3D mentioned - from a sampled portion of each disc rather than the whole film, so read these as "does it move", not as totals:

Cars 2 - 32 offset sequences, 5 dynamic, values -1..10

Cars 3 - 32 sequences, 5 dynamic, values 2..23

Hugo - 32 sequences, 10 dynamic, values 2..30

Aquaman - 32 sequences, 23 dynamic, values -3..12

Alita - 32 sequences, 12 dynamic, values 1..10

Coraline - 2 sequences, 1 dynamic, values 1..4

So NTM-3D is right that dynamic depth is the norm; the static-depth sample on the wiki is the unusual one.

Happy to send the tool so you can point it at any disc you already own, or to cut a short clip if you would rather have something playable. The parse is a pure function with no platform dependency, and it is verified off-hardware against two independent implementations of the same format (LAVFilters and OFSExtractor).

The other half is the MPLS: which offset sequence a given PG stream uses, from the STN-SS extension. Upstream libbluray does not expose ss_offset_sequence_id - several forks add it. I have a working parse of that table as well.

I do have this implemented and confirmed on hardware, but on Amlogic/CoreELEC rather than Pi, so the rendering end is not directly portable; the parsing and the MPLS side are. If it is something you want in scope, I would rather fit it to what you are doing than push a PR at you.

(Disclosure, since you mention it in this thread yourself: the survey and the parser were done with Claude Code, posted from my account.)