3D Support builds for Raspberry Pi

Ah nice, I can use that with my cheapo Amazon remote clones and CE + LE boxes.

Quote from ht2tweak

Ah nice, I can use that with my cheapo Amazon remote clones and CE + LE boxes.

hard not to use them when you got like 6 laying around. All the original shield remotes died with rechargable batteries, so they all go replaced. I have 3 2019 pro s, 3 2015s, 1 2015 pro ( with 500gb ssd) Only using like 2 of them at the moment. I use a onn pro 2024 in the master bedroom. but yeah, i figured why not use them, I wasn't grasping that it used avrc profile for the audio , and that threw me when it paired with libreelec. This was the fix that worked. yay!

Guys, I know this sounds silly, but is the 3D picture on popcornmix PI5 LibreELEC fork maybe just a tad sharper than on the Zidoo? ht2tweak already mentioned it in his YouTube video. Technically, I can hardly imagine it, but every time I watch an MVC 3D video on the PI5 and then on the Zidoo, it seems to me like it’s a bit sharper on the PI5 . Anyone else?

Glad I'm not crazy to have thought so :). It was immediate for me when I first tested popcornmix's build; there was a bit of a wow factor. Forget which 3D title, but recall the opening studio logo having more of a punch, then of course the actual movie.

Maybe a quick feedback regarding the Netflix add-on that I tried to install but failed:

Since this 3D build is based on the Kodi 22.0-BETA1 (Piers) branch, it looks like the underlying Python and HTTP library changes in Kodi 22 break the CastagnaIT Netflix add-on’s network requests (resulting in the 404 / pathEvaluator errors). CastagnaIT currently targets stable Kodi 20/21 releases, so bleeding-edge Kodi 22 builds may run into compatibility issues with how the add-on routes its API calls.

However, please take this information with a pinch of salt – I was accompanied by Gemini - just wanted to drop this info here, nothing more. And thanks again for your awesome work!

I guarantee CastagnaIT is developing and testing against K22 codebases; Gemini came up with horse-poop there.

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.)

Quote from popcornmix

Subtitle depth parsing

Tried to try the subtitle depth parsing in the new build but had some issues. Most of the ISOs I tried played the intro in 3D then black screen. If I tried to skip it would result in instant froozen image or black screen. Audio always kept playing. If I skipped for example 10 minutes into the movie, stopped it and the resumed it would play and activate 3D but the image was 2D.

A few of the ISOs i tried however seemed to work and most if not all the ones that had the issues above was Disney/Pixar movies.
I will be able to get logs and even a video of the problem tomorrow if that helps

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.)

Quote from popcornmix

Updated builds in first post. Hopeful improvements:

Enable Blu-Ray menu in more places (e.g. context-menu/Choose playlist/Show Blu-ray menu)

Significantly better BD menu handling. Only have a handful of full 3D ISO's (just 5; small sample size), but menus work well on all but 2. Logs here for those; w/one playback froze after choosing a title, and w/other, like before, title played in odd SBS format. Same title will play in proper over/under if I choose it directly from Kodi chooser.

Other 3D ISO's show menus/submenus perfectly, and chosen titles play perfectly:

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.)