Posts by popcornmix

Quote from vobs

I think Gemini is wrong. The Pi5 appears to output RGB(16-235). On the Zidoo, selecting "Priority RGB444 8BIT for non-4K content" and "HDMI Range 16-235" (important: do not let it on auto!) produces a similar result. All the other options were worse in some way. With these settings, the 3D on my Zidoo is on par with the Pi5, or at least very close. What results do you get when you compare these settings?

Note, this should all just work automatically if all the components in the chain do the right thing.

The EDID from the sink (display) reports the list of HDMI modes it supports.

These include CE/CEA modes (TV-style timings) and IT/DMT modes (monitor-style timings).

There are different default rules for RGB quantisation range: CE/CEA video timings generally use limited range, while IT/DMT timings generally use full range (with some exceptions).

When the source (Pi) outputs HDMI, it can indicate the RGB quantisation range in the AVI InfoFrame. The sink should use that signalling, or the appropriate default for the video format, to interpret the pixel values correctly.

So everything should just work by default. However, it is not uncommon for devices in the chain to get this wrong - for example, a sink might not correctly respect the InfoFrame signalling, or a source might choose or signal the wrong limited/full-range setting. This results in things such as blacks being crushed or looking grey, and whites being clipped.

Colourspace/colourimetry (for example BT.601 vs BT.709) is another similar setting. The source signals the colour encoding in the AVI InfoFrame, and the sink is expected to interpret the pixels accordingly. Again, this should normally work without any manual settings, but interoperability bugs or incorrect signalling can result in incorrect colours.

Quote from NTM-3D

The graphical issues with for example Cars is still present on both RPi4 and RPi5 versions.

Can you test one of these builds for a potential fix for garbled right eye on Cars: Pi5 Pi4

edit: updated links - attempted to clear menu when playing a second disc without stopping first.

Also enabled more BluRay logging. Can you enable logging and Blu-ray specific logging, and reproduce the issue where the 3D menu said you needed a 3d TV.

Quote from ht2tweak

Talking about RPi4 overclocking, worth doing w/RPi5?

That's up to you. I think a pi5 is fast enough that it's not critical to overclock.

But you may find you can get up to 25% extra performance for free, so if you are willing to do some experimentation it may be worth it for you.

I'd say overclocking to 2800MHz is likely to work, 3000MHz needs a bit of luck with the silicon lottery.

If arm_freq=<N> is not reliable adding over_voltage_delta=<M> may help. M is in microvolts.

Try 25000, but you can go higher.

Note: if you push too far, then random crashes are quite likely (although it shouldn't be possible to permanently damage a board).

Quote from ht2tweak

All 23.976 3D MVC MKV's. Kodi is outputting correctly as 23.98. Titan Noir Max, like most DLP projectors are native 60Hz, and they recently implemented 24p for 2D, but not 3D. Us owners are waiting on XGIMI to fix this for 3D, but it isn't high priority for them. I was just wondering if "Allow double refresh rates" and/or "Allow 3:2 pulldown" might help w/motion judder. I'll try them out and report back.

Talking about RPi4 overclocking, worth doing w/RPi5?

Allow 3:2 pulldown just means it will choose a 60Hz display mode for 24fps video if a 24fps mode is not available. So I wouldn't expect a difference with that setting for your display which does support 24Hz.

If you were to force it to 60Hz, I suspect you'll get the same judder as your projector is giving currently (both sound like they are outputting the 24fps with a repeat frame 3 times, repeat frame 2 times cycle) to get to 60Hz.

Quote from ht2tweak

popcornmix, with latest build 20260909195900-6f94f34, MVC MKV's and 3D ISO's have reverted to playing in side-by-side mode. Vs 'Over/under' you had changed default to few builds back.

I'd have assumed FP (so over/under) would be the preference if supported by display and not disabled in advancedsettings. If not FP, then it should use your preference from settings. A log file would be useful.

Quote from ht2tweak

My projector is currently doing 6:4 cadence for 3D vs 5:5. And its MEMC function does nothing in 3D mode. Would one of the new options you added potentially help with the motion judder present in 3D?

Need a few more details. What is the frame rate of a video with judder? What is the frame rate the kodi is outputting at?

If these are both 24, then this is a projector issue we can't help with. If kodi is driving 60Hz (and projector reports support of 24), then we can look into that.

This post did suggest an overclocked Pi4 was successfully playing. Maybe NTM-3D can report more.

He was trying a test build with performance improvements (seemed to save about 20% performance during MVC playback) - I've just updated the builds on first page to include those.

Quote from ht2tweak

Thanks. I can just try LE off a USB stick and see if 3D works. Which build should I try? I assume popcornmix's work hasn't made it into official stable or nightly yet.

Kodi is heading towards stable release of Piers (stable now, but rc1 imminently), so we're not going to see any of this upstream before that is released and master is back to new features for Q*.

Note, an iPhone has a few interfaces to AirPlay:

If you are playing audio (e.g. music/podcasts), the second page of control centre has an AirPlay button which allows choice of Speaker or "Kodi (LibreELEC)"

To mirror the screen, the first page of control centre has a mirroring button (two overlapping rectangles) which will show "Kodi (LibreELEC)"

When playing a suitable video there will be a AirPlay button near top left (looks like TV). You can choose "Kodi (LibreELEC)".

From the browser it looks like:

From youtube:

I've created an AirPlay receiver addon for Kodi.

It supports screen mirroring, casting videos, and audio.

It is played through Kodi's own pipeline so hardware decoding, the normal renderer and the usual playback controls all apply.

Video protected by DRM cannot be received. Youtube does work.

To test, install the repo zip file and use install from zip file in kodi.

You MUST disable "Enable AirPlay support" in settings/services (this is the old, audio only airplay).

Then you can install Airplay Receiver from the popcornmix repo.

In settings:

* Offer screen mirroring - enables the screen mirror option on AirPlay device

* Play sound from mirroring - if disabled improves latency

* Stream video from apps instead of mirroring - will switch from mirror stream to direct video playback when available

* Let the sender change the volume - adjusts kodi's volume when clients volume is changed

* Low latency mode - disable for now - needs updates to kodi

* Ask new devices to pair - kodi will show a PIN code than needs to be entered on client

Tested on Pi3, Pi4 and Pi5. Built for x86 but untested. Should work on Matrix or Piers.

Source is here.

Quote from Reddog

Even though the projector is showing the correct 3D format I get an error on the screen:

Code

Notice
This TV is not 3D capable.
Please change to 2D signal on your source.

OK

Pretty sure this doesn't come from Kodi. It is likely coming from projector, AVR or splitter.

It depends exactly on how these are connected. Giving a list of hdmi cables connected from device A to device B may help me understand that.

Personally I'd start from the simplest setup (pi connected to projector) and check if that works (without the "Notice") and add the splitter then AVR back in one at a time and see at which point it appears.

Quote from NTM-3D

Cars still has the same glitching. I tried making a sample ISO but the glitching does not show up in that one so the issue may be on another level. See the attached video I made that show the glitching and notice how the time jumps back to 00:57 during the first glitch, playlist issues causing them maybe?

I think that rules out the MVC decoder (it doesn't have the means to make the elapsed time jump).

So, probably at the playlist/demuxer end. Possibly some older packets turning up (causing a timestamp jump backwards and potentially corrupt video frames). I have now got Cars.2006 iso so I'll see if I can reproduce.

Quote from NTM-3D

I was wondering if it would be possible to support MKVs that has prebaked stereo subs? Quite a few on my SBS or OU MKVs has stereo subs. I included a short sample if you need. One problem though is that some like this one has the subs pre squeezed to match the Half SBS/OU format, some are not however are not. So ideally one would have a switch like swap eyes to manually squeeze/unsqueeze if needed.

I may need a sample to understand exactly how the subs are encoded.
I assume you don't mean harcoded subtitles (i.e. in the pixels of the video).

I'm assuming some format where each subtitle's text appears twice for each timestamp, with some positional offset aligning it to left eye or right eye half of screen?

That sounds like a hack to support a media player that doesn't understand 3d.

Without some metadata describing the format it is probably going to be awkward to handle.

Quote from NTM-3D

I have been testing the latest image on the Raspberry Pi 4 and using the default clock speed I get slowdown and stutters but overclocking to 2.1Ghz seems to boost the performance enough to provide smotth playback of 3D Blu-rays, I have not done extensive testing but have tried several high bitrate scenes from different movies.

Had a look on pi4, and seems bluray dependent. Edge of Tomorrow is a lot better than Coraline.

We have up until now been creating a SBS buffer to combine the eyes and pass through kodi's default SBS handling, but that does require a copy of decoded frames which does have a cost. I've had a go at (in the usual DRMPrime path displaying using the decoded frames directly) and it does improve things.

Here is a Pi4 build that may be a bit better - I suspect it will still want an overclock for harder samples, but perhaps can be a little lower. The build also has potential fixes for eye-swaps and subtitle depths. The corruption issue will probably need a sample file.

I asked Claude to to create a sample from BluRay:

## The sample itself

The trick is to keep every byte and every timestamp of the region of interest exactly as the

disc has them, and blank the rest. A **sparse file of the original length** does that: the

`.clpi` seek tables still point at the right offsets, so the playlist opens and seeks

normally, and the file costs only the bytes kept - both on disk and in a compressed archive.

Copy `BDMV` off the disc (or mount the ISO), then, from the copy:

```

cd BDMV/STREAM
CLIP_SECONDS=3048     # length of play item 0 - both 00037 and 00069 cover it
FROM=500              # seconds into the clip to start keeping - a little before the glitch
KEEP=60               # seconds to keep
for f in *.m2ts; do
  size=$(stat -c%s "$f")
  mv "$f" "$f.orig"
  truncate -s "$size" "$f"                      # sparse: same length, all zeros
  case "$f" in
    00037.m2ts|00069.m2ts)
      start=$(( size * FROM / CLIP_SECONDS / 192 * 192 ))   # 192 = one M2TS packet
      len=$((   size * KEEP / CLIP_SECONDS / 192 * 192 ))
      dd if="$f.orig" of="$f" bs=192 skip=$((start/192)) seek=$((start/192)) \
         count=$((len/192)) conv=notrunc status=none
      ;;
  esac
  rm "$f.orig"
done
```

Every other stream on the disc becomes an empty file of the right size, so nothing else has

to be edited: `index.bdmv`, `MovieObject.bdmv`, the playlists and the clip info files all stay

as they are, and the disc still opens, lists its playlists and seeks.

The byte offset is worked out by proportion rather than from the seek table, which is only

approximate on a variable bitrate stream - hence starting well before the glitch and keeping

a generous minute. Playback will begin at the first I-frame after the cut and the demuxer

pairs the two views by timestamp, so an approximate start does no harm.

Then pack it in a way that keeps the holes:

```

cd ../..
tar --sparse -cf - BDMV | zstd -19 -T0 -o drive-angry-sample.tar.zst
```

That should come out at roughly the size of the two 60 second windows.

## If that is too much trouble

Ask instead for `BDMV/PLAYLIST/00100.mpls`, `BDMV/CLIPINF/00037.clpi` and

`BDMV/CLIPINF/00069.clpi` (a few hundred KB in total) plus the exact time. Those settle what

the playlist and the clips claim - which eye is the base view, where the dependent view is,

and what the seek tables say - and are worth having whatever else happens.

Quote from NTM-3D

2. I play Drive Angry via the menu. Graphical issues fairly frequent, mostly in the lower 1/4 of the left eye. Dynamic depth of subtitle works but sometimes flicker back to screendepth.

This could be an MVC issue, or it could be a demuxing issue. A sample file would be useful.

If you are able to extract the movie to an mkv file (still mvc), and test if that has the same glitches, that should narrow it down.

If mkv glitches then it's an MVC decode error, and creating a 1 minute sample with the glitch should be simple.

If not we might need a sample from the ISO, which is a bit trickier to create.

Quote from NTM-3D

popcornmix Have you seen the MVC software decode Jens Duttke has built for the Oku3D player software?https://github.com/jens-duttke/edge264-mvc
I have tested this player alot and the MVC decoding is very good and stable.

I also know of this project, https://github.com/5ymph0en1x/SyLC, that also has a MVC software decoder. But I have not tested this player myself.

In case any of these are of any use

I'd not seen that. Looks like SyLC uses the decoder from edge264-mvc.

The benchmark numbers do show that ffmpeg is faster (30%) than edge264-mvc, and integrating a different decoder into kodi (which only uses ffmpeg) would be tricky. Possibly trying to wrap edge264-mvc into ffmpeg would be easier.

But integrating into ffmpeg is probably best. I'm not aware of any current issues with the MVC part. It's the bluray demuxing and state switching through menus/chapters where most of the fiddly stuff is.

Quote from KaraokeAmerica

I tried playing a movie with TrueHD 7.1. It plays it fine, but my AVR only shows "multi input" not Atmos like it normally does. I have my Kodi settings to 7.1 audio but can't find any other settings specifically related to Atmos. Is there anything else I need to tweak for this to work?

Atmos should just work if you have passthrough enabled in system/audio settings. Make sure TrueHD passthrough enabled and that kodi is playing a TrueHD audio track.