Beiträge von frr

  • Debian 10, XFCE4 WM, softhdvaapi startet im Fenster und verliert Focus...

    Hmm. Ich spiele weiter mit dem Einfall, etwas automatisch zu tun, abhängig von in welchen Workspace der User sich momentan umschaltet. Ich habe mich wmctrl und xdotool angeschaut... beiden sind eigenständige Programme in der Kommando-Zeile. Und ich ekle mich etwas vor der Möglichkeit, wmcrtl sekündlich zu rufen (einen extra Prozess jedesmal zu starten). XDOtool sondern hat eine Library, die ich in meinen eigenen "Pieces" verwenden könnte... aber z.b. keine "bindings" für Perl. D.h. daß wenn ich etwas sparsames schreiben möchte, würde das reines C bedeuten. Na warum den nicht.


    Anders habe ich auch bemerkt, daß obzwar es angeblich eine Funktion gibt, ein Fenster zu "minimieren", namentlich "iconify" in X11 genannt, es gibt anscheinend keinen Gegenteil ein Fenster zu maximieren, oder sondern in den fullscreen Modus zu setzen. Das muss der Programm selber tun, oder? Ich könnte dem softhdvaapi im "maximiertes Fenster" Modus ein Click der Maus senden, um ihn zu sagen, das Fenster in den fullscreen umzukonfigurieren. Aber... wie würde ich durch wmctrl oder xdotool herausfinden, in welchem Mode sich das Fenster momentan befindet? Ich muss damit noch etwas spielen... aber es wird mir langsam klar, das es wahrscheinlich einfacher wäre, die Sache in den Quellen von softhdvaapi zu finden und einfach ändern+rekompilieren :)


    ===EDIT===

    Ahh, Quatsch - bei dem wmctrl gibt es eine relevante Option -b toggle. Es kann ein Fenster horizontal und/oder vertikal maximieren, und es kann auch fullscreen einstellen.


    ===EDIT===

    Okay... also wmctrl und xdotool funktionieren bei mir fast nicht. Und obzwar ich ein Kommando bei xdotool gefunden habe, das das softhdcuvid Fenster nach vorne bringen kann, habe ich kein Kommando gefunden, womit ich den Focus zwingen könnte. Unabhängig von der "anti-focus-theft" Option in den WM-Tweaks. Und, ich habe wirklich keine Weise gefunden, wie den aktuellen Status des softhdcuvid Fensters heraus zu finden. Also irgend eine Hoffnung in dieser Richtung ist Quatsch :)

    Es ist aber sicher möglich, durch wmctrl zu finden, welcher Workspace momentan geöffnet ist: wmctrl -l arbeitet normal. Und ps, kill und andere Kommandos arbeiten sicher normal :)


    Letzten endes sollte ich vielleicht eine IR-Fernbedienung in Betrieb setzen - dabei hoffentlich gibt es kein Problem mit dem Focus. Und wann ich mit dem Desktop spielen will, beleidigt mich nicht, die Maus zu greifen.

  • X11/XFCE, softhdvaapi beim Umschalten der virtuellen Konsole

    Zum Thema möchte ich bestätigen, daß das laufende VDR sich bei umschaltung zwischen XFCE4 Workspaces ganz gut benehmt. Ich verwende bisher eine PC-Tastatur anstatt Fernbedienung und VDR im fullscreen-modus reagiert zu seinen eigenen Kommandos und der WM reagiert zu CTRL+F1 bis CTRL+F4. Also wenn ich auf einen anderen Workspace umschalte, spielt VDR einfach weiter. Audio läuft weiter, Video natürlich nicht mehr sichtbar ist, aber es wird wahrscheinlich dekodiert, weil die CPU-Belastung sich nicht ändert. Das ist wahrscheinlich ganz in Ordnung.

    Wenn ich noch etwas extra mit wmcontrol+xdotool schaffe, werde ich irgendwas positieves hier melden.

  • Debian 10, XFCE4 WM, softhdvaapi startet im Fenster und verliert Focus...

    Meine Herren -- diesmal möchte ich einen kleinen aber wichtigen Erfolg melden :)

    Der Focus ist endlich in Ordnung.

    Die Option in den XFCE4 Einstellungen heisst "Activate focus stealing prevention". Erreichbar unter Window Manager Tweaks -> Focus.


    Es gibt da eine andere geheimnisvolle Option die lautet "Honor standard ICCCM focus hint". Die hat keinen Einfluss - wahrscheinlich weil softhdvaapi sich in diesem Punkt gut benehmt.

    In demselben Tab gibt es auch "When a window raises itself". Keine wichtige Option, aber ich habe "do nothing" ausgewählt, um sicher zu sein. Ähnlich, unter Window Manager -> Focus gibt es "Automatically give focus to newly created windows". Das habe ich auch ausgeschaltet... obzwar bin ich nicht ganz sicher, daß das die korrekte Wahl ist. Das sollte sich später zeigen, wann meine Kinder lernen mit den Workspaces zu arbeiten. Diese zweien Options haben jetzt keinen Einfluss, weil es keine neu-geöffneten Fenster in dem System gibt.


    Der HTPC benehmt sich jetzt grundsätzlich nüzlich. Jetzt werde ich die "user experience" noch etwas polieren :)

    Gibt es manche Möglichkeit, dem softhdvaapi zu sagen, die clicks zu ignorieren? Um in dem full-screen Modus immer zu bleiben (die Fensterdekoration nie zu zeigen). Wenn es keine solche eingebaute Option gibt, muss ich das extern anordnen.


    Spielen mit wmctrl und xdotool wird bis morgen warten. Heute möchte ich etwas früher schlafen gehen :)

    Danke noch mal...

  • X11/XFCE, softhdvaapi beim Umschalten der virtuellen Konsole

    Meine Herren,

    ...mal wieder eine noob-Kategorie-Frage. (Ich versuchte im Forum zu suchen, habe aber keine guten Ergebnisse erhalten.)


    Kurz zu meinem HTPC: Debian 10 auf J4105-ITX, VDR + softhdvaapi, XFCE4 mit xfwm4, kein xfce4-panel, aber 4 Workspaces.


    Heute im morgen, als ich versuchte das "theft of focus" etwas zu untersuchen und zu beschreiben, habe ich aus X (mit laufendem fullscreen softhdvaapi) durch CTRL+ALT+F1 in die erste Text-Konsole umgeschaltet, und ging weg von dem Rechner für ca eine halb-Stunde. Nach meinem Zurückkehren habe ich beobachtet, daß auf der Text-Konsole manche Fehlermeldungen aufgetaucht haben, von dem i915 Treiber (leider habe ich derzeit keine Kopie, auf Anfrage kann ich das reproduzieren) - das irgendwas nicht resettiert werden konnte. Etwas rund um der Buffering von Video, denke ich. Die Tastatur auf der Konsole war fast kaputt. Reagierte nicht sofort zu CTRL+ALT+F7, auch NumLock reagierte nicht. Ich habe mich über SSH angemeldet und da arbeitete alles normal - und nach ca einer Minute reagierte auch die Konsole und umgeschaltete sich zurück in den VDR auf X11. Aber: das Bild war statisch (keine Bewegung), nur jede ein paar zehnten Sekunden hat sich ausgetauscht. Manches Audio gab es, aber es gab Pausen auch in dem Audio.


    Ich glaube daß das softhdvaapi dieser Situation nicht geeignet ist - daß es Versucht, die Audio/Video-Ausgabe dem VAAPI weiter zu liefern, obzwar das fullscreen Fenster jetzt einer unsichtbaren virtuellen Konsole entspricht. Eigentlich die Audio-Ausgabe wird dem PulseAudio übergeben - weiss ich nicht ob es durch VAAPI passt, oder ob der vdr-plugin-softhdvaapi direkt mit dem PulseAudio redet. Ich habe keine Ahnung, wessen Verantwortung es ist, die "Bewegung des Users unter den virtuellen Konsolen" zu verfolgen, und die Lieferung der A/V Daten entsprechend zu pausieren / zeitweilig zu unterbrechen. Und z.B. das Audio könnte wahlweise im Betrieb bleiben, während der User auf einer anderen Konsole arbeitet? Anders bin ich sicher gerne, daß (falls?) der VDR-Engine im Betrieb bleibt, sodaß planmäßige Aufnahmen normal arbeiten.


    Ehrlich gesagt geht es mir kaum um die Text-Konsole. Eher, ich habe vor, manchmal auf einen anderen Workspace in X11 umzuschalten, z.B. den Browser zu öffnen... Soetwas habe ich noch nicht ausprobiert. Im allgemeinen muss ich noch mehrere Aspekte dieses Einfalls testen - gebt mir bitte Beschied, wenn der ganze Einfall ganz dumm ist :)


    Vielleicht noch eine Frage dazu: gibt es manches Kommando in der Fernbedienung (remote.conf), womit man absichtlich den A+V Stream abschalten kann? Sodaß nur das statische OSD auf dem Bildschirm bleibt. Sollte ich einen unerreichbaren Kanal in dem channels.conf eingeben, und an den umzuschalten? Oder gibt es manche reinere Weise, in dem GUI "auf Neutral zu schalten" ?


    Danke für euere Zeit


    Frank

  • Debian 10, XFCE4 WM, softhdvaapi startet im Fenster und verliert Focus...

    Zitat von SurfaceCleanerZ

    Welcher Windowmanager? Openbox?

    Das ist eine gute Frage :) Ich habe an dem WM nicht herumgebastelt - also es sollte das Default sein. XFWM4 ?

    ps sagt

    xfwm4 --display :0.0 --sm-client-id 2a7598460-ca8e-4db1-8129-71df09e46bfd

    Zitat von jojo61

    Den softhdvaapi kann man mit -f direkt im Fullscreenmodus starten.

    Danke :) Damit startet jetzt mein HTPC direkt in dem "Fernseher mode" = es ist fast perfekt.

    Aber VDR benehmt sich wie beschrieben: ich muss in dieses "fullscreen Fenster" klicken, um es in den "windowed mode" umzuschalten, und erst danach arbeitet die Tastatur (wie in dem remote.conf konfiguriert).


    Hmm... ein kurzer Augenblick in die Konfiguration des WM's und WM Tweaks sagt mir, daß es noch was zum testen gibt. Das muss leider bis Abend warten :( Gleich jetzt habe ich "compositing" ausgeschaltet, in dem Bild ergibt das keinen Unterschied, vielleicht spart es 0.5% CPU (der WM ist konfiguriert, fullscreen Fenster direkt zu zeigen) und die Tastatur vs. Focus benehmen sich ganz ebenso (wie mit "compositing" eingeschaltet).

  • Debian 10, XFCE4 WM, softhdvaapi startet im Fenster und verliert Focus...

    Guten Tag meine Herren,


    also vaapidevice und softhdvaapi grundsätzlich beide arbeiten unter Debian 10 auf meinem J4105-ITX HTPC, und ich versuche die Konfiguration des Systems etwas zu finalisieren.

    Und ich bin mal wieder ratlos :)


    Ich habe einen extra User in Linux eingerichtet, habe ich in dem lightdm autologin konfiguriert, und in den XFCE4 "Startup applications" habe ich ein Script zugefügt, der VDR startet.

    Und das komische Problem bleibt, daß VDR in einem Fenster startet, und wann ich das Fenster clicke, um damit VDR in den Fullscreen Mode zu umschalten, verliert VDR "focus" und will nicht mehr zu der Tastatur reagieren. Wenn ich das Fenster klicke, es umschaltet sich in den "windowed" Mode und reagiert weiter zu der Tastatur. Aber klicke ich nochmal, VDR umschaltet sich in den FullScreen, und das OSD nimmt nur eine Taste aus der Tastatur, dann aufgibt den Focus und reagiert nicht mehr... bis ich das FullScreen "Fenster" nochmal klicke, und so weiter.


    Ich habe sondern den xfce4-panel aus dem XFCE4 gelöscht, sodaß es in dem Bild nicht "blendet" und sodaß es den Focus nicht stehlt... aber das hat nicht geholfen. Die Workspaces sind jetzt ganz leer, es gibt keine anderen Apps / keine Fenster auf den Workspaces, und trotzdem verliert softhdvaapi den Focus.


    Ich dachte daß es in den Docs manche Möglichkeit gibt, den VDR+softhdvaapi direkt im FullScreen mode zu starten. Aber habe ich keine solche Option gefunden...


    Vielen Dank im Voraus für jegliche Einfälle :)


    Frank

  • softhdcuvid jetzt mit VAAPI und HDR support

    Zitat von jojo61

    frr Schön wenn es nun läuft. Hast du das vaapidevice mal mit den neuen ld.so.conf einstellungen compiliert ??

    jojo61 Danke daß Sie sich kümmern :)

    Das Mysterium rund um die Libs im vaapidevice ist mir kein großes Problem.

    Aber ja, das war sicher eine der ersten Sachen die ich versucht habe:

    Code
    cd /usr/src/vdr-2.4.1
make clean
make clean-plugins
# ./configure --prefix=/usr  # gibt es eine? Bin ich nicht mehr sicher
make -j 4
make install

    Ich habe durch dem Log zurück gelesen, daß die Plugins wirklich neu kompiliert und linkt wurden und neu installiert.

    Anscheinend alle Dateien wurden erneuert, aber es hat nicht geholfen.

    Dasselbe habe ich später mit dem FFMPEG getan.

    Auch kein Unterschied.

    Vielleicht sollte ich noch kucken, welche headers die Kompilier-Stufe ladet? Die werden von dem ldconfig nicht umgeschaltet...

    Aber es ist mir jetzt etwas egal :)

    Ich könnte darauf noch mal wieder mit strace kucken - um manchen Unterschied in der Liste der geladenen Libs zu finden.

    Wichtig ist, das softhdvaapi für mich arbeitet, und daß ich auch vaapidevice anwenden kann, sollte ich mich dazu noch zurückkehren wollen.

  • vaapidevice: OSD beim Start erst zu klein; Pixelsalat

    Also ich habe mich endlich etwas bewegt. Durch der Wochenende habe ich den softhdcuvid ausprobiert - namentlich die Variante softhdvaapi ohne libplacebo. Und es arbeitet ganz gut! Oberflächliche Unterschiede zwischen vaapidevice und softhdvaapi, in meinem Fall:


    VAAPIDEVICE

    Das aktuelle vaapidevice leidet gelegentlich an den Pixelsalat - bei Umschaltung unter MPEG2 Programme, wie früher beschrieben. Anders arbeitet es ganz gut, z.b. keine Probleme mit dem auftauchen des Window Managers in dem Full Screen Mode, und flüssig ist es auch genug. Und, es hat den eigenen "debug Ausgang" = die ca 3 Zeile durch dem Playback, mit etwas detaillierten Daten über dem spielenden Programm. Es ist auch stabil - unter normalen Umständen hat es nie gestorben oder gefroren. Bei dem Start bleibt das Menü durch ein paar Sekunden in manchem "leeren" Status, aber das beleidigt mich nicht. Während des Betriebs, spielend MPEG2 576i oder H.265 540p, frisst vaapidevice ca 13% der J4105 CPU (durchschnitt der allen Kernen). Deinterlacing auf 576i arbeitet nur in dem "bob" mode (Deinterlace=1) und die obige Pixelreihe flimmert. Das weave=2 mode arbeitet nicht (artefakte sichtbar), und bei dem "motion dynamic = 4" mode stirbt VDR nach einen paar Kanal-Umschaltungen.


    SOFTHDVAAPI

    Das aktuelle softhdcuvid ergibt nie jeglichen Pixelsalat, und war bisher unbedingt stabil. Hat mir nie gefroren oder gestorben. Wann/wenn ich VDR aus einem Terminalfenster auf dem XFCE Desktop starte, und in den FullScreen umschalte, habe ich jedesmal das Problem daß beim ersten verwenden der Tastatur, der Terminal über dem FullScreen auftaucht. Ich muss das Terminalfenster minimisieren, dann ist typisch alles in Ordnung. Es hat mir auch einmal passiert, daß die XFCE "Leiste" (taskbar) aufgetaucht hat - und wollte nicht wieder verschwinden, sondern wann ich das VDR Fenster als "always on top" bezeichnet habe. Es gibt unter dem softhdcuvid keinen "on-screen Debug Ausgang", aber das is kein großes Problem, der Femon zeigt die wichtigste Info auch und man braucht das normalweise nicht, wann alles korrekt konfiguriert ist. Bei dem Start bleibt das Bild durch ein paar Sekunden schwarz und ohne Menü - kein Problem. Während des Betriebs, spielend MPEG2 576i oder H.265 540p, frisst softhdvaapi ca 7-9% der J4105 CPU (durchschnitt der allen Kernen) = ist sparsamer als das vaapidevice ! Deinterlacing auf 576i arbeitet in dem "bob" oder "weave" mode (Deinterlace=0 oder 1) und die obige Pixelreihe ist immer in Ordnung (flimmert nicht). Andere Modi des Deinterlacers habe ich nicht ausprobiert, weil die Anleitung sagt daß sie nicht arbeiten.



    Ich habe leider derzeit keinen Multiplex mit HD Material, nur SD. Das wird sich im ende Januar verbessern.

    Also die CPU-Load Ziffern entsprechen meiner Situation, wo das empfangene Material in 576i oder 540i auf einen Full-HD Bildschirm skaliert wird - durch HW Offload, denke ich? Und, im Sommer mit vaapidevice erinnere ich mich, daß es damals einen HD Kanal gab, und daß er ganz flüssig/glatt war.


    Noch eine Bemerkung zu dem HDMI Ausgang:

    Mein Fernseher - etwas billiges von Vestel - hat die Full-HD Auflösung (1920x1080), und die über DDC übermittelten EDID Daten enthalten 1080i@50/60Hz, aber 1080p nur auf 24/25/30 Hz = der Fernseher gesteht keine Fähigkeit von 1080p auf 50 oder 60 Hz. Es ist üblich und bekannt, daß in solchen Fällen der Fenseher die höhere Bild-Frequenzen oft eigentlich unterstützt (z.B. auf VGA Eingang sind sie sondern von meinem Fernseher angeboten). Darum habe ich die übliche Lösung angewendet, wo man eine Modeline durch xorg.conf erzwingen kann. Ich habe eine Modeline "selbst" kalkuliert = mithilfe umc --cvt generiert. (Spezifisch nicht CVT-R). Dot clock cca 141.5 MHz. Mit dieser Modeline sah mir das Bild in X (XFCE) etwas verwischt aus - etwa wie bei analogem VGA mit unpassender Auflösung. Die Buchstaben in Xterm waren etwas unklar usw. Aber die äusere Geometrie des Bildes passte auf meinen Bildschirm, und der Fernseher meldete 1080p@50, darum arbeitete ich damit. Ich habe bemerkt daß xrandr meldete 1080p@49.97 oder soetwas, d.h. etwas ungleich 50 Hz.

    Später, während ich mit vaapidevice und softhdvaapi spielte, und die zwei Plugins zu vergleichen versuchte, habe ich in dem Bild etwas unregelmässiges beobachtet. Etwa wie mikroskopisches Zittern. Besonders sichtbar durch Video-Sequenzen wo sich manche scharfe Kante oder Rand in dem Bild langsam bewegt. Cca jede Sekunde würde der Playback winzig "stottern". Bei dem vaapidevice war es scharf und momentan, etwa wie ein Bild "ausser Sequenz". Bei dem softhdvaapi sah es eher aus, als wenn der Playback durch einem Augenblick langsamer und dan wieder schneller ging... Und es ist oft schwierig zu unterscheiden, ob der "Stotter-Effekt" in dem Video-Material ist, oder in dem lokalen System entsteht - weil es in dem Material wirklich solche Effekte gibt (oft grober als mein lokaler Video-Mode-Defekt - siehe unten).

    Interessant war, das der Stotter-Effekt von der CPU-Belastung ganz unabhängig war. Ich konnte im hintergrund FFMPEG mit make -j 4 kompilieren, und das Video lief ohne jegliches Problem weiter - nur der Stotter-Effekt war immer da.

    Also unter den verschiedenen Sachen die ich testen wollte, es kamm die Zeit noch mit der Modeline etwas zu spekulieren :) In diesem Forum (dvb-portal.de) habe ich eine andere Modeline getroffen - und ich werde sie hier wortgleich wiederholen:

    ModeLine "1920x1080@50" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync

    Der leere Rahmen (unsichtbar, rund um dem Bildschirm) ist bedeutsam grösser als in meinem CVT Mode, und auch die "dot clock" ist entsprechend höher. Das Bild auf meinem Fernseher ist jetzt sichtbar schärfer :) Die Terminal-Buchstaben sind 100% scharf.

    Und am wichtigsten: das regelmässige sekündliche Stottern ist weg :)


    Also ich habe jetzt zwei funktionierende Ausgang-Plugins: vaapidevice und softhdvaapi. Beide mit HW-offload. Dast ist doch toll! :)


    Die ältere Version des vaapidevice, vor dem "Umbau der Buffers", habe ich ehrlich nicht getestet. Ich kann, wenn das jemanden noch interessiert. Ehrlich gesagt möchte ich mich jetzt auf andere Probleme rund um den HTPC konzentrieren :) Ich wollte noch lirc untersuchen, ich möchte die Tuner-Dongeln endlich in das Gehäuse einbauen (zuerst habe ich vor, sie aus dem Kunststoff knacken und bessere Kühlung ihnen zu geben), auf meinem RTLSDR-Skyline gibt es noch auch manche Arbeit usw.

  • softhdcuvid jetzt mit VAAPI und HDR support

    Zitat von jojo61

    Da stimmt etwas mit deiner ffmpeg installation nicht. libavfilter und libavutil vertragen sich nicht. Sind wohl aus unterschiedlichen ffmpeg versionen.

    Sie haben natürlich recht - Danke :)

    Noch zu dem Problem mit den Libs, strace hat folgendes gezeigt:

    Code
    openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libavutil.so.56", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libavcodec.so.58", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/lib/libavfilter.so.7", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/lib/libavformat.so.58", O_RDONLY|O_CLOEXEC) = 4

    Hm. Es ist sicher meine eigene Schuld, daß ich Sachen direkt mit "make install" installiere, anstatt zuerst einen .DEB daraus zu machen.

    Die Version aus dem Debian Repo hat wahrscheinlich als eine Dependency mit manchem anderen Programm gekommen.

    Also als ein Workaround habe ich /lib auf die erste Zeile in /etc/ld.so.conf eingefügt, und ldconfig durchgeführt. Danach arbeitet das softhdvaapi schon normal - fast ausgezeichnet, eher :)

    Komisch ist, das danach vaapidevice nicht mehr arbeitet. VDR mit vaapidevice startet, aber ohne das Bild, nur mit Audio. Auch top sagt mir, daß die CPU-Kerne nicht so belastet sind, als wann es das Bild gibt. Wann ich die Zeile mit /lib aus ld.so.conf entnehme, startet vaapidevice wieder normal. Ich habe versucht, VDR und FFMPEG mit /lib in dem ld.so.conf wieder zu übersetzen und re-installieren, aber das hat gar keinen Effekt... vielleicht später kann ich das weiter forschen, jetzt gibt es keine Zeit mehr und ich habe schon einen arbeitenden Ausgangs-Plugin. Halelujah :)

  • VDR remote.conf: Kommando um VDR rein zu beenden?

    jsffm danke für den Einfall :)

    Mir geht es um die Situation wo ich jetzt verschiedene Konfigurations-Options testen möchte. Dabei kann das Betriebssystem laufend bleiben. Nur um VDR zu beenden, muss ich mit der Maus etwas arbeiten, um mich in ein anderes Fenster zu tauschen (in den Shell wo ich VDR gestartet habe) und erst da kann ich den VDR-Prozess töten. Mit einer RII-Minitastatur ist es sondern etwas unbequemer...

    Mit einem Taster auf der Fernbedienung wäre es einfacher.

  • VDR remote.conf: Kommando um VDR rein zu beenden?

    Guten Tag,


    durch meinem Spielen mit VDR würde ich nützlich finden, ein Kommando auf der Fernbedienung zu haben, um VDR rein zu beenden. Sodaß das Program sich mit exit() zurück in den Shell kehrt. Für "Produktionsbetrieb" würde ich das Kommando aus remote.conf später abnehmen.

    Z.b. das kommando Power bedeutet anscheinend etwas anderes: VDR bleibt laufend, aber kann einen externen Programm rufen, um den Betriebssystem still zu setzen (oder einzuschläfern).

    Danke im Voraus für jegliche Ideen :)


    Frank

  • softhdcuvid jetzt mit VAAPI und HDR support

    Guten Tag,

    jojo61 danke für die Arbeit auf dem softhd plugin...

    Ich habe mich gestern den frischen vdr-plugin-softhdvaapi übersetzt. Gut dokumentiert, ohne probleme kompiliert. Nur bei dem ersten Start erhalte ich folgenden Fehler:

    Code
    vdr: /lib/libavfilter.so.7: symbol av_sscanf version LIBAVUTIL_56 not defined in file libavutil.so.56 with link time reference

    Ein bloßer ldconfig hat keinen Effekt.

    Libplacebo habe ich nicht einkompiliert. Die erforderlichen Libraries habe ich aus dem Debian 10 Repo installiert:

    aptitude install libglew-dev freeglut3-dev libglm-dev

    FFMPEG ist 4.2.1 von GIT-Quellen, lange vor den oben bemerkten Libs durch make install in das System eingebracht.

    VDR 2.4.1 und die frische VAAPI wurden auch von Quellen kompiliert (VAAPI aus dem GIT).


    Wann ich den vdr-plugin-vaapidevice anstatt vdr-plugin-softhdvaapi lade, startet VDR ohne jegliches Problem.

    Der ganze Script lautet

    Bash
    #!/bin/sh
VDR_BIN='/usr/bin/vdr'
VDR_PLUGINS_DIR='-L /usr/lib/vdr'
export ALSA_DEVICE=default

$VDR_BIN $VDR_PLUGINS_DIR --plugin="softhdvaapi -a pulse" --plugin=femon --plugin=wirbelscan

    Eher als ein Coder bin ich ein System-Klempner.

    Ich versuchte mit Google und auf dem vdr-portal.de zu suchen, aber es gibt keine passenden Ergebnisse.

    Leider habe ich die 20 Seiten dieses Threads nicht hindurch gelesen (TL;DR).

    Ich wäre dankbar für irgend einen Rat :)

  • t2scan: neues DVB-T/T2 Channel Scan Tool basierend auf w_scan

    Noch ein Bisschen weiterer "Analüse":


    In dem Kernel auftaucht FE_READ_STATUS in drivers/media/dvb-core/dvb_frontend.cnatürlich in dem ioctl() hadler. Der Fehlerkode -EREMOTEIO wird in dem Treiber meines Front-Ends verwendet: drivers/media/dvb-frontends/si2168.c . Nur in einer Funktion die ganz nah zu der Hardware arbeitet - die sendet Kommandos dem Front-End Chip über I2C. Entschuldigung für Pseudocode und Englisch:

    Code
    si2168_cmd_execute() {
// -EREMOTEIO gets returned on three different occasions:
  A) i2c_master_send(cmd->wlen) != cmd->wlen  // cmd write error
  B) i2c_master_recv(cmd->rlen) != cmd->rlen  // response read error
  C) ((cmd->args[0] >> 6) & 0x01) > 0    // front-end silicon indicates error
}

    Ich habe in diesem Treiber folgende Änderungen gemacht - nicht in der si2168_cmd_execute() , eher in deren rufenden si2168_read_status(). Dreie extra "debug-Meldungen", wo das Problem auftaucht. Den Patch habe ich als eine Datei unter diese Nachricht eingeschlossen. Und in dem dmesg-Log habe ich jetzt:

    si2168_read_status(): failed to set the delivery system

    Also wir wissen schon, auf welcher Stufe es passiert. Vielleicht der Front-End Chip selbst meldet den Fehler?

    Und noch eine Sache wundert mich: in dem User-Space t2scan auftaucht das Problem nur in dem scan.c auf Zeile 2850.

    Ich habe bemerkt, daß das ioctl(FE_READ_STATUS) auch später verwendet wird: durch funktion check_frontend()auf Zeilen 2360 und 2383 = innerhalb der "scan-Schleife". Und, da wirft es keine Fehler! Komisch. Ich habe keinen Grund gefunden. Nirgendwas, was bei dem ersten Rufen auf Zeile 2850 unterschiedlich wäre. Z.b. das "front-end device" ist da schon geöffnet (anders würde das ioctl gar nicht erfolgen mit dem Treiber zu sprechen.)

    Ich möchte darüber spezifisch die Treiber-Maintainer in linux-media fragen... Haben Sie dazu manchen weiteren Kommentar? Sollte ich z.B. die dev_dbg() Meldungen in dem Treiber entkorken, und einen Log aufnehmen? Oder lassen wir das sein? :)