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.
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).
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.
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.
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.
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.
Even though the projector is showing the correct 3D format I get an error on the screen:
CodeNotice 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.
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.
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.
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.
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.
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.
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.
Builds in first updates to address issues reported.
Note: I'm testing with slightly different files - I've found and improved some issues that are similar to what was failing in reports, but there could still be issues I didn't see. Please test and report what was fixed and what wasn't.
