Video Treiber für Odroid-N2+ (softhdodroid)

Klaus Schmidinger's git trees - vdr.git/blob - osd.h

Um dieses Verhalten bei pixmap layer 0 richtig zu implementieren.

Das sieht man bei skinlcarsng wenn Beschreibungen eingefadet werden.

Oder hier: http://git.tvdr.de/?p=vdr.git;…06054bad2a2;hb=HEAD#l1202

Quote from jojo61

Leider habe ich nicht so ganz verstanden wo die gebraucht wird.

OK, ich versuche das nochmal zu erläutern.

Eine Pixmap mit dem Layer 0 ist beim VDR ein Sonderfall.

Normalerweise werden Pixmaps gemäß ihrem Layer übereinander gerendert. Je Höher der Layer einer Pixmap, umso weiter oben liegt sie. Wenn jetzt eine Pixmap, die weiter oben liegt, eine Transparenz hat (pixmap->SetAlpha()), dann sieht man die darunter liegende Pixmap entsprechend der Transparenz.

Eine Pixmap mit dem Layer 0 hat keine Transparenz, auch wenn eine gesetzt wird. D.h. alles was unterhalb einer Pixmap mit Layer 0 liegt, ist nicht mehr zu sehen. Und das soll mit dem Patch korrigiert werden, weil sich bisher die Layer 0 Pixmap genau so verhält, wie die anderen Pixmaps.

Was liegt unterhalb einer Pixmap mit Layer 0: das OSD selbst.

Man kann ja vieles, was man mit einer Pixmap machen kann, auch direkt mit dem OSD machen.

z.B.: pixmap->DrawText() vs. osd->DrawText()

Gutes Beispiel dafür ist der Skin LCARS, den der VDR selbst mitliefert.

Ich z.B. habe das im Skin lcarsng bisher übernommen und lasse dann trotzdem für die Anzeige der Beschreibung einer Sendung oder Aufnahme, ein Fenster als Pixmap darüber zeichnen. Das funktioniert nur richtig mit einer Layer 0 Pixmap, weil ich dadurch den Hintergrund weg bekomme und trotzdem das Fullscreen-Video transparent durchscheinen lassen kann. Mit anderen Pixmap Layern funktioniert das nicht, weil dann immer noch der Hintergrund durchscheint.

Ich habe hier leider kein Gerät zum Testen, das mit Deinem Ausgabedevice zusammenarbeitet.

Du kannst das aber auch leicht selbst testen, mit dem skinlcarsng.

Post

RE: [skinlcarsng] segfault in displaymenu.c (gelöst)

Achja, ein letztes, was ich vergessen habe. Bei DrawDescription, fehlen in der linken oberen und unteren Ecke noch ein DrawRectangle mit clrTransparent, oder? Zumindest wärs dann "schöner"...
https://www.vdr-portal.de/inde…achment/47919-069ofb-png/

rell

Jun 29th 2023

Das dort von rell , angehängte Bild zeigt den Fehlerfall (ohne Patch), zu sehen an dem durchgehenden Kursorbalken und den Ecken, an den Rundungen.

Mit Patch sollte der Kursorbalken im Beschreibungsfenster nicht zu sehen sein und die Ecken auch die Hintergrunfarbe besitzen.

Das Beschreibungsfenster kannst Du im Setup vom Skin einschalten.

Grüße

kamel5

Ich habe mir nochmal das Umschalten näher angesehen, weil sporadisch die aktivierte Option BlackPicture ignoriert wird. Beim Kanalwechsel sieht die Reihenfolge der abgearbeiteten Kommandos so aus:

1. SetPlayMode wird mit 0 (pmNone) aufgerufen
2. Dort wird das Video schwarz geschaltet (disable_video 1)
3. Vom vdr wird die Funktion Clear() aufgerufen. Im Plugin wird VideoResetPacket aufgerufen und ClearBuffers = 1 gesetzt
4. In VideoDecodeInput wird wegen ClearBuffers die Funktion CodecVideoFlushBuffers aufgerufen
5. CodecVideoFlushBuffers ruft amlReset() auf
6. amlReset ruft InternalClose auf. Durch das Schließen des devices werden die Buffer in der Hardware gelöscht.
7. Anschließend ruft amlReset InternalOpen auf. Das device wird wieder geöffnet und dabei das Schwarzbild schon jetzt wieder deaktiviert (disable_video 0).
8. in VideoDecodeInput wird stream->ClearBuffers auf 0 gesetzt
9. Jetzt setzt vdr SetPlayMode(1), dabei wird das Schwarzbild erneut deaktiviert (disable_video 0) - was es eigentlich aber schon durch das bereits erfolgte Wiederöffnen des devices ist
10. in VideoDecodeInput wird wegen AV_CODEC_ID_NONE jetzt jedoch CodecVideoClose aufgerufen
11. in CodecVideoClose wird InternalClose aufgerufen, wodurch das device wieder geschlossen wird
12. In VideoDecodeInput wird wegen AV_CODEC_ID_H264 CodecVideoOpen aufgerufen
13. CodecVideoOpen ruft InternalOpen, wodurch das device wieder geöffnet wird
14. InternalOpen setzt ein drittes mal disable_video 0

Die einzelnen Schritte sind nicht alle gegeneinander abgesichert und die Reihenfolge ihrer Ausführung mag schwanken, da hier die Logik von vdr über das frühe Setzen des PlayModes 1 mit reinspielt. Es ist auch möglich, das zu rasch hintereinander erfolgende disable_video-Befehle, die sich gegenseitig aufheben, von der Hardware gar nicht erst verarbeitet werden. Eine weitere Erkenntnis ist, dass unnötigerweise doppelt ein Schließen und Öffnen des devices erfolgt. Man könnte nun in CodecFlushBuffers den Aufruf von amlReset rausnehmen (ja, ich erinnere mich, dass ich selbst der derjenige war, der ihn hier im März reingepatcht hatte...). Eigentlich wäre das aber schon die richtige Stelle, um getriggert durch Clear bzw. ClearBuffers so früh wie möglich den Decoder zu leeren. Ich habe deswegen versucht, in VideoDecodeInput anzusetzen und dort das Schließen zu unterdrücken. Aber selbst wenn ich bei AV_CODEC_ID_NONE das device dort nicht schließen lasse, wird es im darauf folgenden CodecVideoOpen doch gleich wieder geschlossen:

if (isOpen && !pip) {
InternalClose(pip);
}

Man müsste da viel tiefer eingreifen. Einstweilen habe ich folgende Vorschläge, die ich hier nicht als Patch reinstelle, sondern Schritt für Schritt erläutere:

In SetPlayMode rausnehmen:

-            if (ConfigVideoBlackPicture) {
-                amlSetInt("/sys/class/video/disable_video", 0);
-            }

In InternalOpen das enablen des Videos bzw. Aufheben des schwarzen Bildes ebenfalls rausnehmen:

-    if (!pip)
-         amlSetInt("/sys/class/video/disable_video",0);

Dafür in CodecVideoOpen ergänzen:

InternalOpen (decoder->HwDecoder,videoFormat, FrameRate);
+    amlSetInt("/sys/class/video/disable_video",0);

Reduktion des Codes, der bei jedem Kanalwechsel ausgeführt wird. Dazu aus InternalOpen diesen Block rausnehmen

+    r = ioctl(cntl_handle, AMSTREAM_IOC_SYNCENABLE, (unsigned long)1);
+    if (r != 0)
+    {
+            //codecMutex.Unlock();
+            printf("AMSTREAM_IOC_SYNCENABLE failed.\n");
+            return;
+    }
+
+    r = ioctl(cntl_handle, AMSTREAM_IOC_AVTHRESH, (unsigned long)2700000); //entspricht 90000*30 in kodi
+    if (r != 0)
+    {
+                    //codecMutex.Unlock();
+                    printf("AMSTREAM_IOC_AVTHRESH failed.\n");
+                    return;
+    }
+
+    r = ioctl(cntl_handle, AMSTREAM_IOC_SYNCTHRESH, (unsigned long)1);
+    if (r != 0)
+    {
+            //codecMutex.Unlock();
+            printf("AMSTREAM_IOC_SYNCTHRESH failed.\n");
+            return;
+    }
+

und in VideoInit() hinter

VideoSetFastSwitch(ConfigVideoFastSwitch);

velegen. Das sind alles Einstellungen, die nur 1x beim Öffnen des Plugins und beim Attachen ausgeführt werden müssen. Während des Betriebs ändern sich die Einstellungen nicht, es reicht daher, sie einmal zu initialisieren.

In gleicher Weise sollte auch

-    // set the system blackout_policy to leave the last frame showing
-    amlSetInt("/sys/class/video/blackout_policy", 0);

von amlReset in VideoInit verlegt werden.

In CodecVideoFlushBuffers sollte der Aufruf von amlReset() erstmal auskommentiert werden, solange ein tiefgreifenderer Umbau im Plugin nicht stattgefunden hat. Bei einer laufenden Wiedergabe erfolgt dann beim Jumpen (Springen mit den gelben/grünen Tasten) das Clearen des Decoders mittels amlReset ausgelöst in ProcessBuffer.

Mit all diesen Änderungen habe ich auf der Tanix TX3 (S905X3) ein spürbar schnelleres Umschalten.

Mir fiel ferner auf, dass beim Beenden des Plugins manchmal das letzte Bild sichtbar bleibt. Dazu habe ich bei mir noch ergänzt:

static void StopVideo(void)
{
VideoOsdExit();
+    amlSetInt("/sys/class/video/disable_video", 1);
//restore decoder default settings
+    amlSetInt("/sys/class/video/disable_video", 0);

Fastswitch habe ich auch aktiv. Längere Umschaltzeiten kann ich nicht nachvollziehen. Den großen Geschwindkeitsvorteil merke ich allerdings auch eher bei DVB-C-Sendern. Bei iptv-Sendern (MagentaTV) fällt es weniger deutlich auf, ist aber keinesfalls langsamer.

Das gelegentliche Nichtaktualisieren der Bildansicht bei Schnittmarken kann ich jetzt nachvollziehen. Was ist, wenn Du in CodeFlushBuffers den amlReset nicht auskommentierst?

Mit Auskommentierung ist der Ablauf wie folgt:

1. Clear() ruft VideoResetPacket auf und setzt ClearBuffers = 1
2. in VideoDecodeInput wird wegen stream->ClearBuffers CodecVideoFlushBuffers aufgerufen
3. CodecVideoFlushBuffers macht nichts!
4. in VideoDecodeInput wird stream->ClearBuffers auf 0 gesetzt
5. SendCodecData ruft vor CheckinPts amlReset auf
6. amlReset wird ausgeführt, da Status isOpen
7. amlReset ruft InternalClose mit Parameter 0 auf
8. InternalClose wird mit pip=0 aufgerufen
9. amlReset ruft InternalOpen auf

Der amlReset() wird hier also in SetCodecData durch eine ermittelte pts-Differenz ausgelöst

        if(lpts  && ((pts & 0xffffffff) + 0x10000 < lpts)) {
            //printf("PTS wrap\n");
            amlReset();
        }

Möglicherweise klappt das bei eng beieinanderliegenden Schnittmarken nicht zuverlässig. Ich habe ja auch klar gesagt, dass das Leeren der Buffer durch Clear ausgelöst werden sollte, deshalb ist es eine Krücke, das doppelte Leeren dadurch zu unterbinden, dass es an der eigentlich richtigen Stelle nicht ausgeführt wird. Schau doch erstmal, ob die Probleme behoben sind, wenn Du in CodecFlushBuffers den amlReset wieder ausführen lässt. Schick mir sonst auch gerne mal Deine geänderte Source zum Gegenkontrolle.

den Abschnitt solltest Du noch ändern:

@@ -2008,6 +2008,9 @@ static void StopVideo(void)
     //restore decoder default settings
     amlSetInt("/sys/class/video/blackout_policy", 1);   //do this here to avoid freezing the last frame
     amlSetInt("/sys/class/tsync/slowsync_enable", 1);
+    amlSetInt("/sys/class/video/disable_video", 1);
+    //restore decoder default settings
+    amlSetInt("/sys/class/video/disable_video", 1);

die letzte Zeile muss den Parameter 0 enthalten. Wenn eine andere Applikation (kodi oder irgendeine X Anwendung - siehe beta-Script- beim Öffnen nicht explizit das Bild enabled, bleibt es schwarz. Ich habe das nachvollzogen - der Parameter bleibt so auch beim Beenden von vdr/softhdodroid auf 1

Sehr schön.

Ich habe bei mir in void InternalClose noch anstelle des auskommentierten Aufrufs vor dem close

//amlClearVideo();

es so eingetragen, wie es c2play in der gleichnamigen Funktion an der Stelle macht:

    r = ioctl(cntl_handle, AMSTREAM_IOC_CLEAR_VIDEO, 0);
    if (r < 0)
    {
        printf("AMSTREAM_IOC_CLEAR_VIDEO failed.");
    }

Ob das noch einen Unterschied macht, will ich nicht beschwören, aber schaden tut es zumindest auch nicht.

Meine Tanix TX3 (mit angeschlossenem DVB-C-Stick) schaltet inzwischen schneller um als mein großer Nvidia-VDR

Es wäre m.E. übrigens inzwischen angebracht, den FastSwitch-Modus als Standardeinstellung zusetzen:

int ConfigVideoFastSwitch = 1;   ///< config enable fast channel switch

Quote from Dr. Seltsam

Ich habe bei mir in void InternalClose noch anstelle des auskommentierten Aufrufs vor dem close

Code

//amlClearVideo();

es so eingetragen, wie es c2play in der gleichnamigen Funktion an der Stelle macht:

Code

    r = ioctl(cntl_handle, AMSTREAM_IOC_CLEAR_VIDEO, 0);
    if (r < 0)
    {
        printf("AMSTREAM_IOC_CLEAR_VIDEO failed.");
    }

Ob das noch einen Unterschied macht, will ich nicht beschwören, aber schaden tut es zumindest auch nicht.

Das ziehe ich zurück. Nach dem Wechsel von Rückwärtsspulen zu Play läuft das Bild damit unrund. Wahrscheinlich war das der Grund, warum Du es ausprobiert, aber auskommentiert hattest.

ich verwende das Plugin aktuell unter in einer Ubuntu (https://wiki.odroid.com/odroid-n2/os_images/ubuntu/20220622) chroot Umgebung unter CoreELEC - da läuft alles prima.

Jetzt versuche ich einen weiteren VDR ohne CoreELEC direkt unter oben genannten Ubuntu auszusetzen. Ich bekomme auch kurz Bild und Ton jedoch bleibt der VDR relativ schnell komplett hängen sodass ich nur noch mit einem reboot weiter komme.

Bevor ich den Fehler näher beschreibe und das log poste erst mal die Frage, hat das jemand so laufen bzw. geht das grundsätzlich oder sollte ich statt der 22.04 die von jojo im git genannte Ubuntu 20.04 verwenden?

Danke, Grüße Jörg

4.9er ist es

~> uname -a
Linux odroid 4.9.337-33 #1 SMP PREEMPT Thu Jul 20 18:05:01 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

okay dann versuche ich es nochmal mit dem 20.04

muss es das minimal sein oder geht auch die Version mit Desktop wenn ich zum VDR Betrieb den Desktop und X beende?

falls es hilft es einzugrenzen, mit der 22.04 bekomme ich das seküdlich im Log:

Sep 25 11:58:18 odroid vdr[3404]: [softhddev]Clear: 20ms buffers 246
Sep 25 11:58:18 odroid vdr[3404]: [3416] [softhddev] vom VDR kommt Clear:
Sep 25 11:58:18 odroid kernel: spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Sep 25 11:58:18 odroid kernel: aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1
Sep 25 11:58:18 odroid kernel: spdif_b keep clk continuous
Sep 25 11:58:18 odroid kernel: aml_spdif_close
Sep 25 11:58:18 odroid kernel: audio_ddr_mngr: frddrs[0] released by device ff642000.audiobus:spdif_b
Sep 25 11:58:18 odroid kernel: aml_spdif_open
Sep 25 11:58:18 odroid kernel: audio_ddr_mngr: frddrs[0] registered by device ff642000.audiobus:spdif_b
Sep 25 11:58:18 odroid kernel: set normal 512 fs /4 fs
Sep 25 11:58:18 odroid kernel:          set spdifout clk:6144000, mpll:24576000
Sep 25 11:58:18 odroid kernel:          get spdifout clk:6143997, mpll:24575987
Sep 25 11:58:18 odroid kernel: aml_dai_set_spdif_fmt , fmt 0x4010
Sep 25 11:58:18 odroid kernel: set normal 512 fs /4 fs
Sep 25 11:58:18 odroid kernel:          set spdifout clk:6144000, mpll:24576000
Sep 25 11:58:18 odroid kernel:          get spdifout clk:6143997, mpll:24575987
Sep 25 11:58:18 odroid kernel: spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Sep 25 11:58:18 odroid kernel: aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1Sep 25 11:58:18 odroid vdr[3404]: [softhddev]Clear: 20ms buffers 246