dfatmo und vaapidevice / VDR 2.4.0

Hi,

ich versuch gerade mein Atmolight mit dem neuen, vaapi-basierten VDR und dfatmo zum laufen zu bekommen. softhddevice hatte da ja eine eigene Funktion eingebaut, ich bin mir nur nicht ganz im klaren ob die optional war/ist, oder ob es auch ohne gehen sollte (die wurde ja bei vaapidevice entfernt).

Kompilieren von dfatmo ging problemlos, aber wenn ich es tatsächlich aktivieren will kommt

May 06 20:56:28 vdr2 vdr[12080]: [12183] DFAtmo grab thread started (pid=12080, tid=12183, prio=high)
May 06 20:56:28 vdr2 vdr[12080]: [12184] DFAtmo output thread started (pid=12080, tid=12184, prio=high)
May 06 20:56:28 vdr2 vdr[12080]: [12182] animator thread thread ended (pid=12080, tid=12182)
May 06 20:56:28 vdr2 vdr[12080]: [12183] DFAtmo: grab function returned wrong image size (24798,27648)!
May 06 20:56:28 vdr2 vdr[12080]: [12183] DFAtmo grab thread ended (pid=12080, tid=12183)
May 06 20:56:54 vdr2 vdr[12080]: [12084] frontend 0/0 lost lock on channel 2 (ZDF HD), tp 111361

Geht so bei jedem Startversuch, lediglich die tatsächliche Grösse (24798 im obigen) ist jedesmal etwas anders. Wenn ich im Code danach suche seh ich dass dfatmo ohne softhddevice ein normales GrabImage macht,

uint8_t *grabImg = cDevice::PrimaryDevice()->GrabImage(grabSize, false, 100, grabWidth, grabHeight);

Hat sich da was im neuen VDR geändert, und es geht deswegen schief, oder kollidiert da eher was mit vaapidevice?

Nutzt wer so ein (altes) Atmolight erfolgreich mit vdr 2.4.0/vaapidevice?

Hmm, das ist doch für vdpau? Wie krieg ich das auf dem Geminilake zum laufen?

Oder meinst' nur wg. vdr 2.4.0? Da hast natürlich recht - an dem kanns eigentlich gar nicht liegen, weil es auf dem alten VDR ja läuft. Andererseits wird da ja dann gar nicht der GrabImage code verwendet :?

Ich kann höchstens mal versuchen beim alten im dfatmo softhddevice abzuschalten....

So letzteres hab ich grad mal versucht auf dem alten VDR, in vdrplug_dfatmo.cpp cPlugin *softHdPlugin = NULL gesetzt.

Damit bekomme ich im Log jede Menge Meldungen

May 07 22:44:00 vdr vdr[8580]: [8624] [softhddev]GrabImage: 0, 0, 100, 128x72

und Atmolight funktioniert. Da obige Meldung (trotzdem) von softhddev kommt heisst das wohl dass das Problem irgendwo bei vaapidevice liegt, oder zumindest am Zusammenspiel mit dfatmo.

Gibt's denn noch andere Plugins, die GrabImage verwenden? Funktionieren die? Mal suchen gehen....

Quote from rofafor

FYI: vaapidevice doesn't support atmo grab service and therefore is using totally different code path in the dfatmo plugin than with softhddevice.

Yes, I'm aware of that - this is what I tried/used when setting softHdPlugin to NULL in dfatmo code on the old machine. It then uses the GrabImage function, and on the old machine this did work.... Still no clue why it doesn't on the new one. The standard svdrp grab command does work on both at least.

Quote from SurfaceCleanerZ

Hi,

Auch softhddevice kann mit VAAPI genutzt werden. Teste doch mal mit EasyVDR3.5 mit aktuellem nachträglich upgegradetem Ubuntu Kernel. Sollte laufen. Ist dann ein 2.2 aber mit softhddevice. Das kann auch VAAPI.

MfG Stefan

Ist das dann eine ältere Version von vaapidevice vor der Umbenennung? Welche? Oder komm ich irgendwo (einfach) an die Paketquellen vom der dort verwendeten Version von softhddevice?

Ok, ich hab vdr-plugin-softhddevice_0.7~git20180203.orig.tar.xz gefunden. Das kompiliert und lädt mit meinem setup, und dfatmo scheint dem log nach auch zu tun - zumindest seh ich keine Fehlermeldungen

Allerdings sitz ich nicht am VDR sondern im Büro, ob alles auch wirklich tut was es soll kann ich erst heute abend checken....

Sorry, hab vergessen zu melden dass es auch einwandfrei läuft: Sowohl Anzeige selbst als auch Zusammenspiel mit DFAtmo sind problemos, lediglich (wie auch mit vaapidevice) gib't ein Audio-offset von ~100ms, und manchmal ist der beim Umschalten im Sekundenbereich und kann erst durch erneutes Schalten auf den Kanal zurückgesetzt werden.

Hmm, da mir vaapidevice deutlich zu gesprächig war hatte ich den loglevel auf 0 gesetzt. An solche Meldungen kann ich mich aber gut erinnern. Allerdings sind (fast(*)) keine Schwierigkeiten sichtbar, drum hatte ich das ignoriert.

Wenn ich allerdings Menü->Softhddevice aufrufe zeigt das ja unten die verdoppelten Frames an, und die zählen in der Tat rasant hoch.

Kann das was mit dem hohen Audio-Delay zu tun haben? Ich werd mal ein wenig experimentieren...

(*)ich suche gerade nach dem Grund für Ruckler, die ich in einigen Aufzeichnungen, aber auch bei manchen Live-Sendern habe...

Hier noch meine config - ich hab da aber nicht wirklich viel rumexperimentiert. Geladen wird das Modul mit

-P softhddevice -f -d :0.0 -a hw:0,3 -p hw:0,1 -w alsa-driver-broken -v va-api

OK, irgendwas ist faul mit dieser Version(*). In der Tat gehen die duped frames hoch, und zwar um 60(!) je Sekunde.

Nein, der Fernseher läuft auf 50Hz. Sowohl TV selbst als auch xrandr bestätigen das. Und der 60Hz Modus ist aus.

Wenn ich ihn einschalte gibt's keine duped frames mehr. Dafür aber dropped frames - 10 je Sekunde.... Bei der Darstellung ändert sich aber nix was mir auffallen würde.

Hab das jetzt gerade auch noch mit der neuesten Version von vaapidevice probiert. Dort tritt es auch auf, allerdings sind's nur etwa 25 duped frames pro Sekunde.

(*)gerade gecheckt. Ich hatte das Archiv von easyvdr, aber das ist identisch mit git version c99afc23a53e6d91f9afa (tag 0.7.0)

Hi Stefan,

kann ich frühestens morgen abend checken, wenn ich wieder daheim bin.

Was ich aber auch schon gesehen hatte: Wenn ich über Menü den 60Hz Modus erst einschalte, und danach wieder aus, bleibt der duped/dropped Zähler auch stehen (total zählt weiter hoch) - bis zum nächsten Senderwechsel.