[ANNOUNCE] vaapivideo 1.5.6

jsffm · April 9, 2026 at 5:58 PM

Ist das ein zweiter Bildschirm?

nobanzai · April 9, 2026 at 6:08 PM

Quote from jsffm

Ist das ein zweiter Bildschirm?

Ja, ein TFT im Gehäuse.

jsffm · April 9, 2026 at 6:11 PM

Dann musst Du den X-Server so konfigurieren, dass nur dieser Bildschirm angesprochen wird.

zork · April 9, 2026 at 7:09 PM

Quote from nobanzai

Irgendwie stelle ich gerade fest, dass ich keine Ahnung von drm habe 8-<
Aber: vaapivideo läuft, erzählt dass es /dev/dri/card1 nutzt und funktioniert dann auch super - Bild und Ton, Fernsehen, Abspielen von Aufnahmen, OSD sind so, wie sie IMHO sein sollten.
Und vor allem auch keinerlei Hänger, wie ich sie gerade bei softhddevice habe.
Danke!

Sagen wir mal so, wenn softhddevice perfekt gewesen wäre, hätte ich ja auch nicht alles neu machen wollen. Ich verwende aus Prinzip nur die aktuellsten APIs und muss mich nicht mehr um Altlasten kümmern. Aktuell arbeite ich sehr stark an der Streamstabilisierung, die nächste Version wird ein großer Schritt nach vorne sein.

zork · April 9, 2026 at 7:14 PM

Quote from nobanzai
Eine Frage trotzdem: Bekomme ich es irgendwie hin, parallel zu vaapivideo einen X-Server laufen zu lassen?
Momentan streiten die sich über den Zugriff auf das DRM-Device:
Code
vaapivideo/display: atomic commit failed - Permission denied (flags=0x400)

Klar geht das, gib einfach den richtigen Pfad zum DRM-Device an. Permissions sollten natürlich auch passen.

0x400 heißt, Dein Device erlaubt kein "nicht blockierendes Atomic-Commit". Das wurde 2015 im Kernel eingeführt. Wie kommts? README.md vollständig gelesen, Testtool laufen lassen?

nobanzai · April 9, 2026 at 7:59 PM

Quote from zork

Klar geht das, gib einfach den richtigen Pfad zum DRM-Device an. Permissions sollten natürlich auch passen.

0x400 heißt, Dein Device erlaubt kein "nicht blockierendes Atomic-Commit". Das wurde 2015 im Kernel eingeführt. Wie kommts? README.md vollständig gelesen, Testtool laufen lassen?

Wie ich schon schrub: Bisher hatte ich nix mit DRM im Sinne von Direct Rendering zu tun und habe daher auch keine Ahnung davon.
Wenn du das README aus deinem Source-Verzeichnis meinst, das habe ich gelesen, aber offenbar den von dir da oben angesprochenen Punkt nicht erkannt oder verstanden.

Was meinst du damit?

Und welches Testtool? vainfo?

nobanzai · April 9, 2026 at 8:00 PM

Quote from jsffm

Dann musst Du den X-Server so konfigurieren, dass nur dieser Bildschirm angesprochen wird.

Ne, leider reicht das nicht, das hatte ich als Erstes schon probiert, nachdem der Fehler bei laufendem X das erstemal aufgetaucht ist.

zork · April 10, 2026 at 12:04 PM

Quote from nobanzai

Wie ich schon schrub: Bisher hatte ich nix mit DRM im Sinne von Direct Rendering zu tun und habe daher auch keine Ahnung davon.
Wenn du das README aus deinem Source-Verzeichnis meinst, das habe ich gelesen, aber offenbar den von dir da oben angesprochenen Punkt nicht erkannt oder verstanden.
Was meinst du damit?
Und welches Testtool? vainfo?

Mit vainfo bekommst Du grundsätzlich raus, ob Dein System vainfo kann. Mit meinem Testtool vaapivideo-probe, das Du selber kompilieren musst (siehe README.md) kann Du ein Device testen, wie gut es "VAAPI" kann. Jedes "Display" hat ein DRM-Device.

nobanzai · April 10, 2026 at 1:52 PM

Quote from zork

Mit vainfo bekommst Du grundsätzlich raus, ob Dein System vainfo kann. Mit meinem Testtool vaapivideo-probe, das Du selber kompilieren musst (siehe README.md) kann Du ein Device testen, wie gut es "VAAPI" kann. Jedes "Display" hat ein DRM-Device.

Hm, also offenbar hat das TFT bei mir kein DRM-Device, da ich nur ein /dev/dri/card1 habe, keine sonstigen /dev/dri/cardx.
Dein Tool meldet dafür:

Code

./vaapivideo-probe /dev/dri/card1
VAAPI Capability Prober (DVB-S2 / YUV420-NV12)
==============================================
DRM device:  /dev/dri/card1
Render node: /dev/dri/renderD128
libva info: VA-API version 1.23.0
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_23
libva info: va_openDriver() returns 0
VA-API:      1.23
Driver:      Intel iHD driver for Intel(R) Gen Graphics - 26.1.4 ()

--- Hardware Decode (VLD + YUV420) ---
  MPEG-2 Main                        yes
                                     (max 2048x2048)
  H.264 Main                         yes
                                     (max 4096x4096)
  H.264 High                         yes
                                     (max 4096x4096)
  HEVC Main 10                       yes
                                     (max 8192x8192)

--- Video Processing Pipeline (VPP) ---
  General (VideoProc)                yes
  Scaling                            yes
  P010 (10-bit) surfaces             yes
  NV12 (8-bit) surfaces              yes
  10-bit -> 8-bit conversion         yes
  Noise Reduction (Denoise)          yes
  Sharpening                         yes
  Color Balance                      yes
  Skin Tone Enhancement              yes
  Total Color Correction             yes
  HVS Noise Reduction                no
  HDR Tone Mapping (HDR10)           HDR->HDR, HDR->SDR

--- DVB-S2 Color Conversion Paths ---
  BT.601 -> BT.709  (MPEG-2 SD)      yes
  BT.709 passthrough (H.264 HD)      yes
  BT.2020 -> BT.709  (HEVC UHD)      yes
  P010 -> NV12      (10->8 bit)      yes
  HLG -> SDR   (no TM required)      yes
  PQ/HDR10 -> SDR    (tone map)      yes

--- Deinterlacing Algorithms ---
  Motion Compensated                 yes
  Motion Adaptive                    yes
  Weave                              no
  Bob                                yes

Display More

Wenn man den X-Server nach Anschlüssen fragt, kommt das dabei raus:

Code

grep "Output" /var/log/Xorg.0.log
[    11.517] (II) modeset(0): Output HDMI-2 using monitor section Monitor_IntelUHD630Fernseher
[    11.554] (II) modeset(0): Output HDMI-2 connected
[    11.554] (II) modeset(0): Output HDMI-2 using initial mode 1920x1080 +0+0
[    11.610] (II) modeset(1): Output DP-2 using monitor section Monitor_IntelUHD630OrigenAETFT
[    11.619] (II) modeset(1): Output DP-2 connected
[    11.619] (II) modeset(1): Output DP-2 using initial mode 800x480 +0+0

Nicht über die Namen wundern, ich bin da manisch, was sowas anbelangt.

seahawk1986 · April 10, 2026 at 2:50 PM

Quote from nobanzai

Hm, also offenbar hat das TFT bei mir kein DRM-Device, da ich nur ein /dev/dri/card1 habe, keine sonstigen /dev/dri/cardx.

Das DRM-Device existiert für die komplette Grafikkarte, nicht für einzelne Anschlüsse - vaapivideo ist bislang auf ein aktives Display limitiert, für eine Konfiguration mit zwei unabhängigen Displays wie das mit xorg möglich ist, tut man sich da schwer.

cinfo · April 10, 2026 at 6:36 PM

zur Info

der aktuelle GIT Stand mit den kleinen Änderung läuft hier sehr gut

Kann man den ersten Start vom Plugin beschleunigen, denn gegenüber den ersten Versionen und anderen Ausgabe Plugins dauert es schon etwas länger bis das erste Bild erscheint. Aber die Umschaltzeiten sind OK.

pixelpeter · April 11, 2026 at 4:03 PM

Hallo Zork,

Der aktuelle GIT Stand läuft bei mir bisher am schlechtesten.

Mal abgesehen das der erste Start wirklich ewig dauert, bleibt bei mir alle Sekunden das Bild kurz stehen.

Im Log sehe ich dann dies hier:

Apr 11 16:00:03 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer primed (buf=25 target=25)
Apr 11 16:00:03 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync ahead d=+123ms -- waiting for audio
Apr 11 16:00:04 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync overshoot correction: dropped 5 frames
Apr 11 16:00:04 vdr1 vdr[1010]: [1023] vaapivideo/decoder: sync d=+247ms avg=+170.5ms buf=18 aq=0 miss=0 drop=0 skip=0
Apr 11 16:00:06 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer underrun -- re-priming (target=25)
Apr 11 16:00:07 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer primed (buf=25 target=25)
Apr 11 16:00:07 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync ahead d=+227ms -- waiting for audio
Apr 11 16:00:07 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync overshoot correction: dropped 4 frames
Apr 11 16:00:08 vdr1 vdr[1010]: [1023] vaapivideo/decoder: sync d=+330ms avg=+157.0ms buf=20 aq=0 miss=0 drop=0 skip=0
Apr 11 16:00:11 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer underrun -- re-priming (target=25)
Apr 11 16:00:11 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer primed (buf=25 target=25)
Apr 11 16:00:11 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync ahead d=+283ms -- waiting for audio
Apr 11 16:00:11 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync overshoot correction: dropped 2 frames
Apr 11 16:00:12 vdr1 vdr[1010]: [1023] vaapivideo/decoder: sync d=+270ms avg=+159.4ms buf=22 aq=0 miss=0 drop=0 skip=0
Apr 11 16:00:14 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer underrun -- re-priming (target=25)
Apr 11 16:00:14 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer primed (buf=25 target=25)
Apr 11 16:00:14 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync ahead d=+172ms -- waiting for audio
Apr 11 16:00:14 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync overshoot correction: dropped 3 frames
Apr 11 16:00:15 vdr1 vdr[1010]: [1023] vaapivideo/decoder: sync d=+270ms avg=+160.4ms buf=16 aq=0 miss=0 drop=0 skip=0
Apr 11 16:00:17 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer underrun -- re-priming (target=25)
Apr 11 16:00:18 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer primed (buf=25 target=25)
Apr 11 16:00:18 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync ahead d=+157ms -- waiting for audio
Apr 11 16:00:18 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync overshoot correction: dropped 3 frames
Apr 11 16:00:19 vdr1 vdr[1010]: [1023] vaapivideo/decoder: sync d=+248ms avg=+152.1ms buf=20 aq=0 miss=0 drop=0 skip=0
Apr 11 16:00:21 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer underrun -- re-priming (target=25)
Apr 11 16:00:21 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer primed (buf=25 target=25)
Apr 11 16:00:21 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync ahead d=+99ms -- waiting for audio
Apr 11 16:00:21 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync overshoot correction: dropped 1 frames
Apr 11 16:00:22 vdr1 vdr[1010]: [1023] vaapivideo/decoder: sync d=+250ms avg=+165.0ms buf=18 aq=0 miss=0 drop=0 skip=0
Apr 11 16:00:24 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer underrun -- re-priming (target=25)
Apr 11 16:00:24 vdr1 vdr[1010]: [1023] vaapivideo/decoder: jitter buffer primed (buf=25 target=25)
Apr 11 16:00:24 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync ahead d=+287ms -- waiting for audio
Apr 11 16:00:25 vdr1 vdr[1010]: [1023] vaapivideo/decoder: prime-sync overshoot correction: dropped 1 frames

Peter

jsffm · April 11, 2026 at 4:47 PM

Der Start dauert bei mir schon seit einigen Versionen ewig ...

zork · April 11, 2026 at 9:48 PM

Release 1.4.0

Overhaul A/V sync, trick/still playback, and audio pipeline

Replace PI drift controller with EMA-based scaled-wait A/V sync; add EMA warmup, residual-accumulator form, and age-compensated clock
Uniform 50 fps pipeline: fps filter duplicates references for 25p/25i so all sources reach SyncAndSubmitFrame() at display cadence
Live hard-ahead path: single large sleep for rawDelta > 200 ms prevents marginal transponders from outrunning the 20 ms/s soft correction rate
Split audio latency into PcmLatency / PassthroughLatency; wire through setup menu, config parsing, and sync controller
Stale audio-clock protection: GetClock() timeout lets video fall back to freerun instead of syncing against a frozen PTS
StillPicture() rewrite: re-entry guard, PES iteration loop, FlushParser() + codec drain, still-picture bypass in SyncAndSubmitFrame
Filter graph for trick/still: bob:rate=frame for HW trick, yadif send_frame for SW paths; deinterlacer omitted for single-frame stills
Filter graph keepalive: old graph moved to previousFilterGraph to keep hw_frames_ctx alive until next overwrite; prevents EIO on PRIME export
Reverse trick PAFF fix: keyframe filter fast-forward only; DPB drain after each field pair instead of per-packet filter-graph reset
IEC958 non-audio bit: SetIec958NonAudio() toggles AES0 via ALSA control to enable HBR mode on HDMI transmitter before passthrough open
Radio channel detection: show black frame when audio plays but no video codec opens within 3 s
Enlarge jitter buffer (500 → 1000 ms) and packet queue (100 → 200) for weak-signal arrival bursts
Harden audio lifecycle: idempotent shutdown, generation-based stale-packet drops, parser reset recovery after repeated decode failures
AVSYNC.md: full rewrite matching new sync architecture, filter-graph and fps-upconversion sections, corrected clock and drop-count descriptions

zork · April 11, 2026 at 9:52 PM

Hi,

bin gespannt, wie die neue Version bei Euch läuft. Ich denke, der AV Sync ist jetzt endlich gut. Mehr Buffer, alle Passthrough-Codecs überarbeitet, Trickmode heile gemacht, Schnittmarken-Steps repariert, etc.

Viel Spaß beim Testen

Offene Punkte: langsamer Start, Race-Condition bei schnellen Jumps. Das braucht ihr nicht mehr reporten.

jsffm · April 11, 2026 at 10:10 PM

Ich schaue jetzt die laufende Aufzeichnung von "Schlag den Star" in 1080i und habe das Gefühl, dass im Bild ab und zu kleine Ruckler sind, hängt verm. mit der A/V Synchro zusammen.

cinfo · April 11, 2026 at 10:13 PM

Quote from jsffm

Ich schaue jetzt die laufende Aufzeichnung von "Schlag den Star" in 1080i und habe das Gefühl, dass im Bild ab und zu kleine Ruckler sind, hängt verm. mit der A/V Synchro zusammen.

kann ich bestätigen -- war vorab bei den anderen Versionen nicht da

jsffm · April 11, 2026 at 10:15 PM

Quote from cinfo

war vorab bei den anderen Versionen nicht da

auch das kann ich bestätigen.

zork · April 11, 2026 at 10:20 PM

Quote from jsffm

auch das kann ich bestätigen.

Ihr seit echt ungeduldig Hier ist der Fix für das langsame Startup (Race-Condition, VAAPI ist da noch nicht "ready").

Diff

diff --git a/src/device.cpp b/src/device.cpp
index 770852f..f19dc3b 100644
--- a/src/device.cpp
+++ b/src/device.cpp
@@ -1001,10 +1001,6 @@ auto cVaapiDevice::Detach() -> void {
    initState.store(2, std::memory_order_release);
    isyslog("vaapivideo/device: initialized - DRM=%s audio=%s", drmPath.c_str(), audioDevice.c_str());
-    // Paint black so we don't expose whatever the last DRM client (or boot splash) left
-    // in the scanout buffer until the first real frame arrives.
-    SubmitBlackFrame();
-
    return true;
}

Display More

zork · April 11, 2026 at 10:34 PM

Den AV Sync habe ich sehr "scharf" eingestellt, 20ms. Wenn das Ruckeln am Anfang (da schwingt sich das System ein) nach ca. 15s noch da ist, bitte mal DECODER_SYNC_LOG_INTERVAL_MS auf 2000 setzen und das Log beobachten. Gerade bei "Schlag den Star", ProSieben HD, bei mir:

Code

Apr 11 22:31:04 vaapivideo/decoder: sync d=-7.1ms avg=-8.7ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:06 vaapivideo/decoder: sync d=-6.1ms avg=-6.9ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:02 vaapivideo/decoder: sync d=-6.7ms avg=-8.1ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:08 vaapivideo/decoder: sync d=-5.3ms avg=-6.1ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:10 vaapivideo/decoder: sync d=-6.6ms avg=-7.5ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:12 vaapivideo/decoder: sync d=-6.5ms avg=-8.9ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:14 vaapivideo/decoder: sync d=-3.4ms avg=-5.0ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:16 vaapivideo/decoder: sync d=-9.6ms avg=-10.2ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:18 vaapivideo/decoder: sync d=-8.0ms avg=-7.1ms lat=40ms buf=29 aq=2 miss=0 drop=0 skip=0
Apr 11 22:31:20 vaapivideo/decoder: sync d=-5.4ms avg=-5.5ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:22 vaapivideo/decoder: sync d=-8.8ms avg=-8.1ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:24 vaapivideo/decoder: sync d=-6.5ms avg=-7.2ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:26 vaapivideo/decoder: sync d=-5.6ms avg=-4.2ms lat=40ms buf=29 aq=0 miss=1 drop=0 skip=0
Apr 11 22:31:28 vaapivideo/decoder: sync d=-1.6ms avg=-3.9ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0
Apr 11 22:31:30 vaapivideo/decoder: sync d=-8.7ms avg=-7.7ms lat=40ms buf=29 aq=0 miss=0 drop=0 skip=0

Display More

So liegt die Differenz immer unter 10ms, das ist perfekter AV-Sync.

[ANNOUNCE] vaapivideo 1.5.6

zork April 11, 2026 at 9:48 PM

Participate now!

zork April 11, 2026 at 9:48 PM

Participate now!

zork April 11, 2026 at 9:48 PM