Posts by popcornmix

    Two minor issues, one of which may be related to Kodi:
    1. If “Invert stereoscopic 3D mode (flip eyes)” is enabled for a movie and then “Set as default for all media” is selected, the latter setting remains in effect until the Pi5 is rebooted. After that, the flip eyes setting is only saved for the movie in which it was enabled. The default for all media is gone.
    2. When a 3D movie is started from the “In progress movies” poster list on the main page, framepacking only works for MKV 3D files, but not for FSBS 3D files.

    Possible fix here: RPi5

    sThis version seems to have fixed all my issues. Skipping around now causes no issues with audio. The two files I found that played a a a frame or two every second now work fine again and opening my main ISO folder i file mode is now instant again. Tried it on the RPi5 but I am updating my RPi4 right now also.

    Thank you :)

    Great bumped first post to those versions.

    I notice a large delay entering my ISO folder now if in file mode. Library open instant, file mode used to open instant but now takes several seconds. I can see that it opens every one of my ISO's in the log.

    Ah, it looks up resume point for each file in directory, and the fixed version goes through a slower path.

    Does this avoid it? RPi4 RPi5

    The other issues in your log may be fixed by the audio revert.

    I've done some work on optimising the MVC decode.

    MVC is trickier to multi-thread, as the right eye typically depends on the left eye, so you can't just work on them in parallel.

    The best I (Opus) could do originally used slice threading which has more overhead.

    I've had another go with Fable to get frame threading working and it is now better than slice threading.

    This should help all platforms, but especially Pi4.

    The subtitle torture test is now smooth for me on Pi4 without overclock (overclock may be useful for harder clips).

    I've updated builds in first post.

    Currently none of the dynamic subtitle tracks are updating properly, there at a lot of missed and inconsistent depth updates. Sometimes seconds between updates.

    I see. For the 1 update per second tracks it looked broadly okay, but with faster updates it’s more obvious many updates are missed.


    It’s when a sub changes depth but not text it may get skipped as it’s not triggering the update as dirty, should have a build tomorrow.

    Regarding 3D subtitles and dynamic depth there are still some ways to go. To help in this I have made this demo disc that has many different variants of dynamic and static depth for subtitles. I even included a torture test that sweeps between the max (127) and min (-127) depths possible with changes every single frame.

    I've downloaded. It would be useful if you could describe where the output is wrong?

    e.g. at 00:30 sub should have increased depth compared to 00:29, but was the same.

    The menu issues are unchanged. Most fail to play the menu but then fall back to playing the movie instead. But on Dune (2021) it crashes when you try to open the menu. No problems playing from the playlist.

    I think most menus you are having trouble with are java ones (2,3,5). You need to install the "JRE for BD-J menus" addon from LibreELEC repo to support those.

    1. wasn't obvious from log. I'd probably need a sample menu that behaves like that to debug further.

    4. looks fixable.

    6. looks like a bad rip:

    Code
    demuxer seek to: 2410868.000000
    bluray.c:925:  Unable to seek clip 00800.m2ts!
    bluray.c:1720: Seek to 9400237248
    bluray.c:824:  Read past EOF !
    Process - eof reading from demuxer
    CVideoPlayer::OnExit()


    the indexes point beyond the end of the file - we hit EOF and end. It may be possible to treat that as switch to next item in playlist which may behave better.

    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.

    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.