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

  • Ich habe es nun nochmal getestet mit -g 1920x1080 oder einer anderen Auflösung kann man die Auflösung einstellen

    Und mit -r 50 oder 60 kann man den Refresh einstellen.

    Also sollte am besten ein -g 1920x1080 und -r 50 in die Konfig.

    Damit geht es auch ohne den Patch. Der ist überflüssig.


    PS: Ich habe nun den Coreelec Kernel 5.15.119 unter Ubuntu 22.04 laufen und boote den Odroid-N2+ über Petitboot (Schalter auf SPI) ohne SD Karte direkt von der SSD.

    Damit brauche ich keine chroot Umgebung mehr und habe ein normales Ubuntu als Entwicklungsumgebung. :)

  • Ich habe es nun nochmal getestet mit -g 1920x1080 oder einer anderen Auflösung kann man die Auflösung einstellen

    Und mit -r 50 oder 60 kann man den Refresh einstellen.

    Also sollte am besten ein -g 1920x1080 und -r 50 in die Konfig.

    Damit geht es auch ohne den Patch. Der ist überflüssig.

    Mist. Ich habe meine Config nochmal überprüft, weil die Parameter mir bekannt vorkommen. Und was sehe ich

    Code
    -r 50
    -r 1920x1080

    Hmmm.... Ich baue nochmal neu ohne den Patch und werde den einen Parameter auf "-g" ändern.


    edit:

    Der ganze Ärger nur, weil ich nicht lesen kann :wand Es funktioniert alles einwandfrei, auch ohne den Patch. Danke.

  • Mist. Ich habe meine Config nochmal überprüft, weil die Parameter mir bekannt vorkommen. Und was sehe ich

    Code
    -r 50
    -g 1920x1080

    Bitte helft mir auf die Sprünge: In welcher Konfig Datei sind die Einträge genau?

  • Dem Hinweis folgend habe ich in codec.c mal auf spdif_b umgestellt und tatsächlich hatte ich sofort Ton und es gab keinen Kanal, der Probleme machte.

    Ich hab mal einen neuen Build mit dem spdif Patch gemacht; jetzt gibt es auch bei mir keine Tonprobleme mehr! :thumbup:
    Falls die Einstellung geräte-abhängig ist, müsste man es wohl als Konfigurations-Parameter machen.


    Schöne Grüße
    Lothar

  • Ich fange mal an, ein paar Patches vorzustellen bzw. zu beschreiben.


    Auch nachdem der isRadio-Counter in AudioEnque schon von 75 auf 150 erhöht wurde, kommt es immer noch gelegentlich zu Bildsprüngen nach einem Kanalwechsel, wenn ConfigVideoFastSwitch nicht aktiviert ist. Die Ursache ist, dass der Zähler bei einem Kanalwechsel nicht zurückgesetzt wird. Wechselt man von einem Kanal, wo keine Videodaten erkannt wurden (Radio oder ein 'Hänger') auf einen Kanal, beginnt der isRadio-Zähler mit dem letzten Wert, z.B. 110. Der neue Kanal braucht vielleicht bis 50.Da er aber schon mit 110 anfängt, wird die A/V-Synchronisation schon nach 40 Durchläufen beendet, und der neue Kanal beginnt mit einem zu schnell laufenden Bild.

    Lösung:

    • in audio c void AudioEnqueue die Variable static int isRadio = 0; in int isRadio = 0;  ändern
    • in softhddev.c
      • über int SetPlayMode(int play_mode) ergänzen:extern int isRadio;
      • in SetPlayMode bei case 0 ergänzen: isRadio = 0; //reset counter in AudioEnque


    Ich bin zudem der Meinung, dass isRadio in AudioEnque nur dann hochgezählt werden sollte, wenn keine Video-PTS vorhanden ist. Und bei einer erkannten Diskrepanz muss es ja Videodaten geben. Dann kann es zwingend kein Radio mehr sein kann, so dass der Zähler zurückgesetzt werden sollte.


    Die Bedingung sehe dann so aus:


    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Die nächste Verbesserung betrifft die Wiedergabe beim Wechseln von Zeitlupe vorwärts (also ein Trickmode, der aus der Pause heraus aufgerufen wird) zu normaler Wiedergabe (Lösen der Pause und Verlassen des Trickmodes durch Play). An der Stelle kommt es derzeit zu einer Bildbeschleunigung, weil der Ton dem Bild ca. 4s voraus ist und das Bild diese Diskrepanz aufholen will, indem es schneller läuft.

    Nach langer Suche habe ich die Funktion Mute ("Turns off audio while replaying") in softhddev.c als Ursache identifiziert. Dort wird SkipAudio = 1; sowie AudioFlushBuffers(); ausgeführt. Nur wenn man beide Aufrufe weglässt, tritt das beschriebene Problem nicht auf. Die Funktion ist dann leer, und es wird im Ergebnis nur die übergeordnete Funktion in softhdodroid.cpp ausgeführt:

    Code
    /**
    **  Turns off audio while replaying.
    */
    void cSoftHdDevice::Mute(void)
    {
        dsyslog("[softhddev]%s:\n", __FUNCTION__);
    
        cDevice::Mute();
        ::Mute();
    }

    Damit ist die Mindestanforderung wie in vdr's device.h definiert erfüllt:

    Code
    virtual void Mute(void);
    ///< Turns off audio while replaying.
    ///< A derived class must call the base class function to make sure
    ///< all registered cAudio objects are notified.

    Der Ton wird dennoch stumm!

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Die nächste Änderung betrifft das Anspielen von Aufzeichnungen mit deaktiviertem FastSwitch. Die Wiedergabe läuft dann verzögert an, und es ist nicht möglich, durch gedrückt gehaltener grüne oder gelbe Taste schrittweise durch die Aufnahme zu springen. Mit FastSwitch funktioniert das, und die Wiedergabe startet auch schneller. Mein Vorschlag ist deshalb, für die Wiedergabe von Aufzeichnungen die gleiche Synchronisationsmethode wie bei FastSwitch zu verwenden. Notwendige Änderungen:


    am Ende von softhddev.c wird eine Funktion (die ich aus softhddevice geklaut habe) ergänzt:

    Code
    int IsReplay(void)
    {
        return !AudioSyncStream || AudioSyncStream->ClearClose;
    }

    in video.c wird hinter extern int m_PlayMode; noch extern int IsReplay(void); ergänzt


    in video.c wird in VideoInit() der Aufruf VideoSetFastSwitch(ConfigVideoFastSwitch); entfernt

    Dafür wird am Anfang von InternalOpen ergänzt: VideoSetFastSwitch(IsReplay() ? 1 : ConfigVideoFastSwitch);

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Weiter geht es. Die nächste Änderung ist etwas kniffliger. Hier hatte ich beschrieben, dass bei jedem Kanalwechsel eigentlich unnötigerweise das device mehrfach geöffnet und geschlossen wird. Die Ursache liegt in der Historie von softhddevice, wo anfangs überhaupt kein Clearen des Decoders beim Kanalwechsel stattfand. Alle settings zum Kanalwechsel erfolgen bei bereits laufendem PlayMode 1.


    Mir fiel das wieder unangenehm bei Tests mit DVB-T2 auf. Irgendwas ist bei HEVC anders, jedenfalls sah man bei jedem Umschalten erst Schwarzbild, dann kam das Bild wieder und erst dann kam das neue Bild.


    Ich habe das daher jetzt so laufen:


    In softhddev.c habe ich an 2 Stellen (VideoPollInput und VideoDecodeInput hinter dem Aufruf von CodecVideoFlushBuffers(stream->Decoder); noch stream->LastCodecID = AV_CODEC_ID_NONE; ergänzt.

    CodecVideoFlushBuffers führt in video.c einen amlReset durch. Besser wäre es gewesen, die LastCodecId dort oder in amlReset zurückzusetzen, aber es ist mir nicht gelungen, diese zu video.c gehörende Variable in softhddev.c anzusprechen.


    Resultat ist, dass in VideoDecodeInput diese Bedingung nicht mehr greift:

    Code
                if (stream->LastCodecID != AV_CODEC_ID_NONE) {
                Debug(3, "in VideoDecode make close\n");
                    stream->LastCodecID = AV_CODEC_ID_NONE;
                    CodecVideoClose(stream->HwDecoder);
                    // FIXME: CodecVideoClose calls/uses hw decoder
                    goto skip;
                }

    da die LastCodecId beim bereits erfolgten Schließen des devices nunmehr auf AV_CODEC_ID_NONE gesetzt wird. Und damit das device beim amlReset() nicht gleich wieder geöffnet wird, erfolgt in video.c in void InternalOpen eingangs eine Prüfung des PlayModes:


    Code
    if (m_PlayMode == 0 && !pip && !isPIP && !PiPActive) {
        //printf("skip InternalOpen because PlayMode=0 and pip, isPIP + PiPActive are false\n");
        return;
    }

    Auf diese Weise wird das bereits geschlossene device nicht unnötig geöffnet, solange der PlayMode noch 0 ist.

    Damit das funktioniert, muss über void InternalOpen(VideoHwDecoder *hwdecoder, int format, double frameRate) noch extern int PiPActive; ergänzt werden. Und in softhddev.c muss die Deklaration der Variablen angepasst werden, damit PiPActive in video.c abgefragt werden kann:

    Code
    -static int PiPActive = 0, mwx, mwy, mww, mwh;          ///< main window frame for PiP
    +int PiPActive = 0;
    +static int  mwx, mwy, mww, mwh;          ///< main window frame>

    Es hat lange gedauert, das so auszutüfteln, dass das geänderte Umschaltverhalten auch mit PIP funktioniert. Aber bei meinen Tests sind jetzt keine Probleme mehr aufgetreten. Das Umschalten geht nach meinem Eindruck so noch mal einen Ticken schneller, auch wenn es nicht spektakulär ist.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Einen habe ich noch.

    Über Probleme beim Umschalten zwischen vdr und kodi hatte ich ja schon mehrfach berichtet. Es kommt da immer wieder zu segfaults, die ich bisher nicht debuggen konnte. Zuverlässig vermeiden konnte ich die Probleme, indem ich beim Detachen auf den Aufruf von VideoThreadExit() verzichte. Dazu habe ich folgende Änderungen vorgenommen:

    In softhdodroid.cpp

    Code
    -static signed char SuspendMode;         ///< suspend mode
    +signed char SuspendMode;                ///< suspend mode

    und in video.c vor void VideoExit(void) { die Zeile extern signed char SuspendMode; ergänzt


    Und dann in VideoExit():

    Code
    -    VideoThreadExit();
    -    sleep(1);
    +    if (SuspendMode == 0) {
    +        VideoThreadExit();
    +        sleep(1);
    +    }

    Damit wird der Video Thread beim Beenden des Plugins sauber beendet. Allerdings weiss ich nicht, was passiert, wenn vdr durch Erreichen der MinUserInactivity oder per Power-Taste beendet wird, während softhdodroid noch suspended oder detached ist..

    Auf meinem System kann das nie vorkommen: Solange das plugin detached ist, kann vdr auch bei Erreichen der MinUserInactivity nicht Runterfahren, und in kodi habe ich den Ausschaltbutton aus dem skin entfernt.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Dr. Seltsam Danke für deine Patches. Bis auf 2 habe ich sie nun übernommen und eingecheckt.

    Das Problem bem Start von Aufnahmen bei deaktivem Fastswitch kann ich nicht nachvollziehen. Bei mir klappt das springen mit grün/Gelb immer bei deaktivem Fastswitch.

    Und dein Patch zur optimierung des Umschaltens ist mir ein wenig zu heiss. Da hast du an einigen kritischen Stellen geändert und das m.E. für wenig Verbessung. Das ganze sieht man auch nur wenn man kein Black on Switch aktiv hat. Deswegen nehme ich den auch lieber nicht mit.


    PS:

    Ich habe nun auch den Ton auf Spdif_b eingestellt. Damit sollte dann auch das Ton Problem beim Kernel 5.15 weg sein.

  • Das Problem bem Start von Aufnahmen bei deaktivem Fastswitch kann ich nicht nachvollziehen. Bei mir klappt das springen mit grün/Gelb immer bei deaktivem Fastswitch.


    Hast Du auch mal probiert, die Tasten gedrückt zu halten? Bei mir läuft der Balken dann zwar weiter, aber das Bild aktualisiert sich erst wieder, wenn man die Taste loslässt. Es sollten aber bei gedrückter Taste fortlaufend aktualisierte Bilder ("Super-Spulen") angezeigt werden. Getestet habe ich mit einer Tagesschauaufnahme von Das Erste HD.

    Quote from jojo61
    Und dein Patch zur optimierung des Umschaltens ist mir ein wenig zu heiss. Da hast du an einigen kritischen Stellen geändert und das m.E. für wenig Verbessung. Das ganze sieht man auch nur wenn man kein Black on Switch aktiv hat. Deswegen nehme ich den auch lieber nicht mit.

    Kannst Du dann bitte wenigstens dies in InternalOpen übernehmen:

    Code
            if (!pip) {
                    PIP_allowed = false;
                    if (m_PlayMode != 0) {
                            amlSetInt("/sys/class/video/disable_video",0);
                    }
            }

    Damit wird das Bild nicht schon beim ersten (vor dem eigentlichen Kanalwechsel erfolgenden) Öffnen wieder angeschaltet. (PIP geht trotzdem noch.)


    Bei DVB-T2 kommt es sonst sogar vor, dass beim Umschalten auf einen Radiosender nach der Schwarzbildphase ein frame vom letzten TV-Bild wieder angezeigt wird. Irgendwas ist da bei HEVC anders.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!