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.

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.

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.

Zitat von Dr. Seltsam

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!

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.

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:

Apr 25 16:57:46 odroid kernel: [ 4190.526016@0] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Apr 25 16:57:46 odroid kernel: [ 4190.526027@0] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1
Apr 25 16:57:46 odroid kernel: [ 4190.526172@0] spdif_b keep clk continuous
Apr 25 16:57:46 odroid kernel: [ 4190.526178@0] aml_spdif_close
Apr 25 16:57:46 odroid kernel: [ 4190.526253@0] audio_ddr_mngr: frddrs[0] released by device ff642000.audiobus:spdif_b
Apr 25 16:57:46 odroid kernel: [ 4190.526800@0] aml_spdif_open
Apr 25 16:57:46 odroid kernel: [ 4190.528187@0] audio_ddr_mngr: frddrs[0] registered by device ff642000.audiobus:spdif_b
Apr 25 16:57:46 odroid kernel: [ 4190.528411@0] set normal 512 fs /4 fs
Apr 25 16:57:46 odroid kernel: [ 4190.528444@0]          set spdifout clk:6144000, mpll:24576000
Apr 25 16:57:46 odroid kernel: [ 4190.528447@0]          get spdifout clk:6143997, mpll:24575987
Apr 25 16:57:46 odroid kernel: [ 4190.528449@0] aml_dai_set_spdif_fmt , fmt 0x4010
Apr 25 16:57:46 odroid kernel: [ 4190.528452@0] set normal 512 fs /4 fs
Apr 25 16:57:46 odroid kernel: [ 4190.528463@0]          set spdifout clk:6144000, mpll:24576000
Apr 25 16:57:46 odroid kernel: [ 4190.528465@0]          get spdifout clk:6143997, mpll:24575987
Apr 25 16:57:46 odroid kernel: [ 4190.528503@0] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Apr 25 16:57:46 odroid kernel: [ 4190.528511@0] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1

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>