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

  • Hallo jojo61,


    ich möchte hier einen Patch (gegen den aktuellen git-Stand) vorstellen, der primär das Umschaltverhalten betrifft. Im aktuellen Stand ist die Geschwindigkeit ohne FastSwitch ja deutlich verbessert, aber was dabei fürchterlich nervt ist, dass es regelmäßig immer mal wieder beim Umschalten den Effekt gibt, dass das Bild für einen Moment viel zu schnell läuft. (Es ist das gleiche Phänomen, dass -unabhängig vom FastSwitch- auftritt, wenn man aus dem Standbild die Zeitlupe vorwärts aufruft und wieder auf Play (Normalgeschwindigkeit) geht. Man kann das mit FastSwitch auchgut reproduzieren, wenn man auf einen Radiokanal geht, einen Moment wartet und noch bevor Ton kommt wieder auf einen TV-Sender wechselt).

    Noch ungeklärt ist, warum das unter VDR*ELEC sehr viel häufiger beim Umschalten auftritt als in einer chroot-Umgebung. Mit aktiviertem FastSwitch hat man hingegen das Problem, dass das Bild zwar sehr schnell da ist und anläuft, dann aber stehen bleibt und auf A/V-Synchronität wartet, ehe es weiter läuft. Das nervt auf Dauer auch gewaltig. Also habe ich nach einem Weg gesucht, das zu verbessern.


    Der anliegende Patch macht mehrere Sachen:


    • In der audio.c wird in AudioEnque ein Bug beseitigt: Die Auskommentierung für skip = AudioSkip; betrifft m.E. nur das Umschalten ohne FastSwitch. Hingegen wird FirstVPTS an mehreren Stellen in video.c verwendet und sollte deshalb m.E. auch für aktivierten FastSwitch auf 0 gesetzt werden.
    • Für das Schwarzschalten während des Kanalwechsels kehre ich zurück zur black policy, die jetzt aber ohne Zeitverzögerung sofort anspringt. Das jeweils richtige Setzen (schwarz oder letzter Frame) wird anhand des PlayModes ermittelt und in amlReset() berücksichtigt. Der amlogic-Parameter disable_video wird zum Umschalten nicht mehr benötigt. Gleichwohl muss er offenbar nach jedem Schließen des devices explizit erneut auf 0 gesetzt werden (macht Kodi auch so). Ich meine, dass die black policy einen Tick schneller funktioniert, wenn es darum geht, den neuen Stream wieder einzublenden. Ein weiterer Vorteil ist, dass -zumindest wenn die letzte Aktion keine Wiedergabe war- das Bild auch bei einem ungeordneten Beenden von vdr (Crash oder killall -9 vdr) schwarz wird. Der bisherige Ansatz in StopVideo hat hier nichts bewirkt, da der Code dann gar nicht mehr zur Ausführung kam.
    • In der Funktion Trickspeed habe ich zur Klarstellung die speed-Werte je Funktion als Kommentar hinterlegt. (Eventuell kann das stattdessen auch in VideoSetTrickspeed in video.c.)
    • Die beiden bools doPauseFlag und doResumeFlag sind m.E. ungenutzt, daher habe ich sie entfernt
    • Einigen toten Code habe ich entfernt. AMSTREAM_IOC_CLEAR_VIDEO bewirkt nichts und wird von Kodi auch nicht verwandt. AMSTREAM_CLEAR_VBUF ist schon im 4.9er Kernel in einem Kommentar als nicht mehr vorhanden beschrieben.
    • Der Clou ist, dass bei aktiviertem FastSwitch Videodaten in CodecVideoDecode verworfen werden, bis in AudioEnque AudioRunning true ist. Dadurch startet das Bild fertig synchronisiert. Lediglich einen kurzen Schreckmoment braucht es, bis dieses anläuft. Das dauert zwar einen Tick länger als vorher, wirkt aber professioneller und ist immer noch schneller als ohne FastSwitch. Ich habe es auch mit Ausführung von AudioVideoIsReady versucht, aber das Ergebnis war weniger befriedigend. Ebenso die Platzierung - in SendCodecData dauert das Umschalten dann länger. Deshalb habe ich auch den Code für "ohne FastSwitch" von SendCodecData mal in CodecVideoDecode verlegt. Die Logik sagt mir, dass es sinnvoll ist, das so früh wie möglich auszuführen.
    • Damit auch die Bildaktualisierung bei StillPicture (Schneiden) funktioniert, musste ich eine neue Variable "inTrickModeStillPicture" einführen. (Beim Schneiden ist weder TrickMode aktiv noch läuft Audio.)
    • Anders als in Deinem letzten commit eingebaut habe ich amlSetInt("/sys/module/amvdec_h264/parameters/dec_control", 4); auch für den Kernel 4.9 vorgesehen - analog Kodi.

    Wie sagtest Du mal so schön - man kann leicht Opfer seiner eigenen Erwartungshaltung werden :) . Im Falle des FastSwitch-Umschaltverhaltens bin ich mir sicher, dass es eine Verbesserung bringt. Ohne FastSwitch meine ich, dass es einen Ticken schneller geworden ist. Aber das will ich nicht beschwören.

    Files

    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

  • habe nun nochmal das 20.04 Image installiert und den VDR ohne update/upgrade laufen lassen. Damit ist es nun seit Samstag Abend stabil und ich musste nicht booten :). Der Kernel des Images ist 4.9.277-122.


    Versuche nun mit apt den Kernel auf 'HOLD' zu stellen und den Rest zu aktualisieren.

  • okay das scheint auch zu funktionieren :]

    Verständnisfrage, muss man nach der Installation von dem im ersten Post hier genannten Ubuntu 20.04 Image sicherstellen das kein Update gemacht wird oder zumindest der Kernel dabei nicht aktualisiert wird? (Ich meine nicht den update auf 22.04, ... sondern nur die Aktualisierung innerhalb der 20.04).

  • Hallo horchi,


    die Frage ist aus meiner Sicht, was im Kernel zu dem Stehenbleiben des Bildes geführt hat. Ist es ein amlogic-Problem auf der Dekoderseite? Oder ein Problem mit den DVB-Treibern (lokales DVB-Gerät angeschlossen?). Das Plugin ist ja vermutlich unschuldig, wenn Du wiederum die aktuellste Version kompiliert hast.

    War denn die Box noch per SSH ansprechbar oder komplett eingefroren?

    Grundsätzlich hat der Kernel von Odroid zwar amlogic-spezifische Anpassungen für die Decoderfunktion, aber er ist nicht so gut gepflegt wie der von CoreELEC. Die haben Insiderinformationen und sind auch beim Kernel 4.9 noch fleißig am patchen. Mein Rat wäre deshalb, auf eine Installation von CoreELEC mit Ubuntu in einer chroot-Umgebung umzusteigen. Es zwingt Dich ja niemand, Kodi zu verwenden :)


    PS: Vielleicht magst Du meinen Patch aus #901 mal testen? Dann haben wir auch eine Rückmeldung von einem Nicht-CE-Nutzer.

    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

  • ja ich habe wieder die aktuelle Plugin Version.
    DVB kann ich ausschließen da es sowohl mit den lokalen DVB Treibern passiert als auch beim Betrieb über streamdev.

    Die Box ist dann noch komplett ansprechbar und alles andere funktioniert dann noch einwandfrei. Nur der VDR läuft erst wieder (bzw. bringt erst wieder Bild) wenn ich gebootet habe.

    Ist es ein amlogic-Problem auf der Dekoderseite

    Woran erkenne ich das bzw. wie kann ich das eingrenzen - vor allem wenn es eins von beidem ist hilft dann diese Informatiuon um ggf. etwas dagegen zu tun?


    CoreELEC mit Ubuntu in einer chroot-Umgebung habe ich im Wohnzimmer da verwende ich der Odroid ausschließlich für den VDR das läuft super stabil.

    Auf dem Odroid im Wohnmobil wird der VDR nur nebenbei verwendet, seine Hauptaufgabe dort ist eine Art Haussteuerung für alle mögliche Hardware und Geräte welche dort verbaut sind. Das alles in chroot ist mir zu frickelig und umständlich. Scheiterte bei meinen Versuchen schon an der dbus Verbindung zum systemd des CE.


    Den Patch kann ich gern testen - ich vermute das er nur mit den Umschaltzeiten zu tun hat und keine Auswirkung/Verbesserung zu dem Problem unter 'pain' Ubuntu?

  • der Patch läuft wie du es beschreibst, das zu schnell laufen (und ab und zu kurz ruckeln) nach dem zappen ist weg, der Ton kommt damit bei mir gleichzeitig mit dem Bild. Das Bild steht hier dann noch kurz (deutlich unter einer Sekunde) dann läuft alles flüssig.
    Finde es damit angenehmer beim Zappen!

  • ich möchte hier einen Patch (gegen den aktuellen git-Stand) vorstellen,

    Ich habe den Patch nun mal ausprobiert und es sieht ganz gut aus. Nur ein Problem habe ich noch. Es gibt kein Schwarzschalten beim Kanalwechsel mehr.

    Egal wie ich es im Config einstelle ich bekomme immer nur ein Standbild des alten Kanals bis der neue dann losläuft.

    Dr. Seltsam wie sieht das denn bei dir aus.


    Edit:

    Ok das mit dem Schwarzschalten war mein Fehler :) Nun geht es.


    Edit2:

    Ich habe es nun eingecheckt.

  • jojo61: Sehr schön, Danke. Ich war schon am grübeln, denn eigentlich funzt das zuverlässig. Immer wenn PlayMode 0 kommt (beim Umschalten oder beim Beenden einer Wiedergabe), wird auch amlReset aufgerufen, und da wird dann die blackout policy gesetzt.

    Eine der drei compiler warnings habe ich übrigens gefixt. Die anderen (aml...) begreife ich nicht - das müsste dann ja an zahllosen anderen Stellen in video.c und softhddev.c auch angemeckert werden...


    horchi: Auf Dein Einfrier-Problem dürfte der Patch keinen Einfluss haben. Hast Du denn überhaupt ein DVB-device lokal angeschlossen oder schaust Du über einen satip-Server? Wenn ein DVB device dranhängt, dann sollte sich da innerhalb der 4.9er-Kernelversionen eigentlich nichts geändert haben. Das setzt natürlich voraus, dass Du ein von Kernel 4.9 unterstütztes Gerät hast. Falls Du die DVB-Treiber nachträglich aktualisiert hast (Paket des Herstellers oder aus linuxtv media_build) würde ich da mal schauen.

    Wenn Du im eingefrorenen Zustand noch per ssh auf das Log kommst, müsste man da mal reinschauen. Bei Ubuntu ist das ja auch /var/log/syslog und überlebt ein reboot.

    Falls Du eingrenzen kannst, ab welcher Kernelversion der Fehler auftritt, könntest Du ein diff der Kernelsourcen machen. Ich habe keine Ahnung, wie umfangreich da überhaupt noch Änderungen stattfinden. Gibt es ein git für den Odroid-Kernel? Ich glaube nicht.

    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

  • ich habe ein lokales DVB Device welches ich verwende wenn ich unterwegs bin - also der normal Betrieb.
    Wenn das Wohnmobil zuhause im Hof steht schaue ich da drin kein TV außer zum testen, dann verwende ich streamdev mit Verbindung zum streamdev Server zuhause da es im Hof mit dem Ausrichten der Schüssel auf dem Wohnmobil etwas knapp ist am Dach vorbei zu kommen.

    In beiden Betriebsarten läuft es mit 4.9.277 stabil und mit 4.9.337 bleibt es nach einiger Zeit hängen - zum Teil erst nach Stunden, je nachdem wie viel ich zappe oder wie oft ich den VDR Starte/Stoppe.

  • habe gerade die Situation mit Kernel 4.9.337, im log kommt dieser Block an Meldungen 2-3 Mal /Sekunde:

    helfen die weiter, habt ihr eine Idee in welchem Bereich das Problem liegt?

    VDR lässt sich nicht mehgr beenden, auch nicht mit kill -9, es bleibt ein defunct hängen: root 8884 3281 3 16:16 pts/1 00:01:25 [vdr] <defunct>

  • horchi Es ist sehr aufwendig, den Hardkernel-Kernel zu fixen/adaptieren. Ohne ein Update der Umgebung läuft es bei mir mit der Ubuntu 20.04-Version sehr gut. Ich hatte damals versucht, den Kernel so zu ändern, dass auch KODI beschleunigt läuft. Das hat zwar funktioniert, ich musste KODI dann aber in einer CHROOT-Umgebung laufen lassen, damit die Beschleunigung funktionierte (das typische libMali-Problem). Das ist das Problem, wenn man nicht für alles den Source-Code hat.


    Was einwandfrei funktioniert, ist CoreElec zu installieren und dann alles in einer chroot-Umgebung laufen zu lassen. Da kann man zumindest sicher sein, dass der Kernel OK ist. Und wenn man den 5.4-Kernel braucht, kann man die -NO-Version nehmen, die läuft auch ganz gut. Über Skripte kann man leicht einstellen, was zuerst booten soll (VDR, KODI oder sogar X11). Ich habe in meinem Github auch ein install.sh-Skript, das eine komplette chroot-Umgebung mit allen Updates installiert (https://github.com/beta68). Für mich ist das immer noch die einfachste Methode. Man kann dann mit einem apt update/upgrade alle Pakete aktualisieren oder mit apt-get nachinstallierten, was man braucht. Man merkt gar nicht, dass man in einer chroot-Umgebung ist. Und sollte Hardkernel den Kernel updaten (zu was, was nicht kompatibel ist), ist das völlig egal für die CHROOT-Umgebung. So hat man die volle Funktionalität und verliert sie bei einem Kernel-Update nicht. Alles andere ist wie gesagt sehr aufwendig und mühsam, nachzuhalten (siehe mein Github und den Kernel darin).


    Das sind aber nur meine Erfahrungen und ich will Dich zu nichts überreden. Richtig kompliziert wird es dann, wenn noch Ambilight dazu kommt. Das lief dann irgendwann mit meinem Kernel, aber es gab Mikro-Ruckler. Da sowieso entweder KODI oder VDR in einer CHROOT-Umgebung laufen muss, damit beides beschleunigt läuft, habe ich es irgendwann aufgegeben, den alten 4.9-Kernel für alles aktuell zu halten. Wenn man KODI nicht braucht, muss man es ja nicht starten...


    P.S.: Die ganze Story kannst hier nachlesen: https://forum.odroid.com/viewtopic.php?f=177&t=43593

  • beta danke für die Erläuterungen, ich habe mir mit CoreElec hier ein ähnliches Setup zusammengestellt damit läuft der VDR auch wie geschmiert. Das verwende ich immer wenn der Odroid nur oder fast nur für den VDR da ist.

    Bei dem Setup um welches es mir gerade geht ist der VDR nur ein kleiner Teil am Rande. In diesem Szenario habe ich ein paar Dinge welche ich im chroot nicht zum laufen bekomme und andere welche recht umständlich sind. Daher wäre es super wenn ich es unter Plain Ubuntu hinbekomme. Aktuell habe ich es mit apt-mark hold linux-odroid-n2 gelöst, nun kann ich einen Update machen und es läuft immer noch.

  • Der Bildsuchlauf vorwärts (speed 1, 3 6) bei h264 sieht "abgehackt" aus. Es läuft wesentlicher flüssiger, wenn dazwischen ein amlReset() wie beim Zurückspulen erfolgt. Da das aber für die Zeitlupe vorwärts nicht richtig funktioniert, muss man diffenzieren. Ein Reset soll für h264 bei jeder Rückwärts-Geschwindigkeit und zusätzlich bei den speeds 1, 3 und 6 (die jeweils vorwärts oder rückwärts stattfinden können) erfolgen. Der geänderte Codeblock in video.c (void CodecVideoDecode) sieht 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

  • Hi jojo61,

    ich habe mir nochmal das Phänomen des bei manchen Kanalwechseln (nur mit deaktiviertem FastSwitch) kurz zu schnell laufenden Bildes angesehen. Es liegt an void AudioEnqueue in audio.c:


    Der Zähler für die Anzahl Durchläufe zur Ermittlung von Radio ist mit 75 zu klein. Ein guter Umschaltvorgang sieht z.B. so aus:

    Die zweite Bedingung (Audio PTS kleiner als Video PTS) wird hier 34 mal erkannt, macht bei 24ms pro Durchgang plausibe 816 ms A/V-Differenz. Was ich aber nicht verstehe: Nachdem der Ton also nicht mehr zurückhinkt, wird dann aber mit der letzten Bedingung noch 11 mal = 264 ms das Gegenteil erkannt - nun ist das Video plötzlich vor dem Ton. Mir ist nicht klar, wie es dazu kommt. Liegt das daran, dass das Audio immer komplett verworfen wird, so dass es zu neuen Abweichungen kommt, wenn die A/V-Differenz nicht durch 24 teilbar ist?


    Wie auch immer, ich konnte debuggen, dass es beim Umschalten immer mal wieder Situationen gibt, wo die erste Bedingung (Clear all audio until video is available) deutlich über 75 hochläuft, ehe doch noch Videodaten kommen. Das passiert immer dann, wenn es irgendwo kurz 'hakt' - sehr gut reproduzierbar ohne radio-Plugin durch Umschalten auf einen Radiokanal und sofort zurück auf einen TV-Kanal. In einigen Fällen habe ich dann bis knapp 150 geloggt.


    Ich habe den Wert jetzt von 75 auf 150 erhöht - seitdem gab es bei keinem Umschaltvorgang mehr zu schnell laufende Bilder. Nachteil ist, dass es auf Radiosendern dann fast 4 s dauert, bis Ton kommt. Aber das kann man ja mit dem radio-Plugin umgehen. Wen das auf PlayPes konfiguriert ist, sendet es die benötigten Videodaten.


    Du hattest irgendwann mal geschrieben, dass Du immer etwas zuviel Audio in den ringbuffer geben musst, damit der nicht leer läuft und es einen alsa underrun gibt. Welche Codestelle ist das?

    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!