Amlogic: wait for HDMI DRM connector before first window init#47
Open
Tristan1019-user wants to merge 347 commits into
Open
Amlogic: wait for HDMI DRM connector before first window init#47Tristan1019-user wants to merge 347 commits into
Tristan1019-user wants to merge 347 commits into
Conversation
… afterwards and the values where lost
…ll Kodi keeps feeding frames to the decoder in pause mode without release. This would cause a buffer overflow. So when paused feed only frames until the buffer is full to not interfere with Kodi internal frame handling.
Some displays advertise VESA modes that they shouldn't. This can cause issues if kodi attempts to default to one of these on displays that don't support 1080p60hz. This also helps simplify handling of video modes for the user by removing most of the less then useful ones.
The contrast/brightness controls under /sys/class/video/ don't work on the newer devices so switch to using the ones under /sys/class/amvecm/ instead
…mes if fps != 0 Skip stream if fps == 0. This will fix black screen on DVD/BD-J video menu.
On some codec types when using Multi Media Modules it's needed to write included extra media data with the first frame instead of writting the data seperatly.
… decoder can handle up to 31 bit numbers only. Because of that a pts backup of bit 32 to 64 is needed before send data to the hardware decoder. By a FIFO deque the backuped pts overflow can be added back to the incoming decoded frame. On some streams the pts sign changes on the first few frames. A deque buffer almost can fix this.
…only if mode or fractional rate changed.
Scaling and other options may be different, even when mode is the same.
Screensaver standby delay setting
…and below. This is only needed for devices with the mali bug.
…on of the file. Also execute when the setting SETTING_COREELEC_AMLOGIC_DISABLEGUISCALING is changed
If you boot the device without hdmi connected /sys/class/display/mode returns nothing which leads to an empty string and "hdmimode=''" Next time you try to boot with hdmi connected kernel will crash.
Kodi will disable it a bit later. This will minimize a bit the flickering when 4K Scaled GUI is used on boot.
…ge This will stop any running splash-image animation
…elay from seconds to minutes.
…ng By the HDMI port option it was not possible to represent all hardware setups available on user side. Also the HDMI port setting was transfered to the corresponding physical address by libCEC on the first init anyway. The physical address in Kodi/input is now set only by user, not by auto detection anymore. If the user change the physical address it will be forced to use user setting instead auto detection.
…sume After suspend the CEC master (TV) should still be available. So no extra ReopenConnection should be needed.
Amlogic uses 'soc_thermal'.
Three issues with interlaced content on Amlogic hardware decoders: 1. video_rate exception logic checked hints.width == 1920 instead of hints.interlaced, missing SD interlaced (576i50) and incorrectly halving 1080p50. Used hardcoded NTSC pulldown math instead of deriving from fpsscale/fpsrate. SD H.264 fps overrides fired for MKV/TS where stream timing is reliable — limit to mp4/avi (codec_tag != 0). 2. Progressive fallback heuristic false-triggered on MBAFF H.264: MBAFF alternates 20ms field / 40ms frame output, and the 40ms frames matched the "double duration" check, halving fps from 50 to 25. Gate on di0 frame_format not confirming "interlace". 3. DI pipeline buffers multiple fields before output but Kodi captures PTS at V4L2 DQBUF (before DI), so frames appear ~240ms late. Shift video start timestamp forward by 12 field periods when interlaced + AML HW decoder + di0 present. This close CoreELEC#41.
Follow-up to the previous interlaced A/V sync PR. Several issues surfaced
during wider testing, particularly around MBAFF H.264 content (1080i50 with
progressive-coded macroblocks) and HEVC progressive content wrongly flagged
as interlaced.
DI pipeline latency compensation (previously start-timestamp-only) is now
also applied to the render manager's displayLatency via a new
SetDeinterlaceDelay/GetDeinterlaceDelay mechanism. The timestamp-only
approach fixed initial sync but not ongoing frame release timing, leaving
video ~240ms behind audio at steady state.
Dynamic DI delay adjustment for mixed interlaced/progressive streams:
MBAFF recap-style content genuinely alternates sections. The DI hardware
adds ~240ms latency when deinterlacing but only ~60ms when passing
progressive through. An audio sync correction channel (via
IAEClockCallback::GetAndClearSyncCorrection) injects the exact difference
into ActiveAE on DI state changes, bypassing the averaging window.
Field counts are exposed as advancedsettings (dipipelinefields=12,
diprogressivefields=3) for tuning.
Several MBAFF edge cases for the progressive fallback heuristic:
- Require positive "progressive" from vfmt rather than "not interlace"
(avoids firing before di0 reports its first reading and halving fps
at playback start).
- Don't let transient DI "progressive" (which reflects the current
macroblock coding type on MBAFF, not the stream) clear the demuxer's
interlace flag.
- Block the fallback entirely when the demuxer has flagged the stream
as interlaced (CODEC_INTERLACED). Trust the demuxer over the
duration heuristic in that case.
- Block CalcFrameRate from halving m_fFrameRate (50 → 25) for
demuxer-flagged interlaced content, since MBAFF progressive sections
make the PTS tracker measure a 25fps cadence.
Fix 29.97/25fps progressive wrongly treated as interlaced: OpenVideoStream
was unconditionally doubling the frame rate and marking interlaced
regardless of hints.interlaced. Breaks HEVC progressive content (di0 is
not in the HEVC pipeline so the vfmt-based correction never fires). Gate
the interlace assumption on hint.interlaced. Also fixes a double-division
bug in the progressive retry fallback (59.94 → 29.97 → 14.985).
This close CoreELEC#42
Drop the DI compensation extensions that regressed pure interlaced MBAFF A/V sync on some devices. The previous `CoreELEC#41` (timestamp-only) approach was already working on multiple hardware targets — `CoreELEC#42` layered on `displayLatency` subtraction and dynamic transition injections that: - Double-compensated against SyncStream's natural DI-latency correction, producing ~240ms overshoot that then oscillated - Were over-fit to the mixed interlaced/progressive MBAFF recap case and broke pure interlaced MBAFF on devices where SyncStream already handled the DI offset correctly (cf. upstream feedback) Reverts: - SetDeinterlaceDelay/GetDeinterlaceDelay on CRenderManager and the m_deinterlaceDelay subtraction in displayLatency - IAEClockCallback::GetAndClearSyncCorrection channel (DVDClock / AudioSinkAE / ActiveAE) - Dynamic DI state tracking and transition injection in VideoPlayerVideo - dipipelinefields / diprogressivefields advancedsettings (no longer used) Kept from CoreELEC#42 (unrelated to DI compensation, still fix real bugs): - 29.97/25fps progressive wrongly treated as interlaced - Progressive-fallback gating (positive vfmt confirmation, CODEC_INTERLACED gate, transient vfmt guard) - CalcFrameRate halving block for demuxer-flagged interlaced streams Mixed interlaced/progressive MBAFF content (e.g. recap episodes) will have the same ~240ms offset in progressive sections as before CoreELEC#42. That asymmetry is a property of the Amlogic DI pipeline and cannot be cleanly compensated in software without fighting SyncStream. This closes CoreELEC#43
Clean up EGL state on failure.
A new buffer must be locked before release the old one to prevent tearing.
Portisch
force-pushed
the
aml-5.15.196-22.0
branch
14 times, most recently
from
0395456 to
61d887a
Compare
Portisch
force-pushed
the
aml-5.15.196-22.0
branch
2 times, most recently
from
a3a15de to
db08685
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
17 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add a bounded Amlogic DRM settle/reprobe path before Kodi initializes the first window against HDMI.
Changes included:
Why
On a CE22 / kernel 5.15 Amlogic test build, Kodi could start while HDMI modes existed but the DRM connector still reported disconnected. In the bad path Kodi fell through into an invalid first GUI/display state. Waiting briefly for the connector/encoder to bind avoids that first-start race without inventing fake connector or CRTC state.
Scope
This is the source-side replacement for the incorrectly-targeted CoreELEC/CoreELEC PR. It is framed as a generic Amlogic DRM initialization race and intentionally does not include Fire TV Cube device-tree work, AVDV UI work, or package-level changes.
Validation