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

  • Hat der Zabrimus CE-Kernel irgendwelche Vorteile gegenüber dem normalen CE-Kernel?

    Ich glaube du läuft da einen Phantom nach. Der Zabrimus Kernel ist der original CE Kernel und bringt bzgl. umschaltzeiten sicherlich keine Vorteile.

    Ich glaube nicht das du die Umschaltzeiten wesentlich schneller bekommst durch Austausch von Kernel oder Treibern. Die verschiedenen Versionen werden sich da kaum bis gar nicht unterscheiden. Um da wirklich weiter zu kommen müsstest du das Umschalten erst mal zerlegen. Wie lange dauert das neue tunen, wie lange dauert es bis der Stream durchgereicht wird, wie lange dauert es bis das erste I-Frame kommt, usw. erst dann kannst du evtl. die Ursache finden.

  • na ja... wenn man das SyncThresh deaktiviert, ist das neue Bild quasi sofort da, und das Bild stockt dann nach meiner Wahrnehmung weniger als 1 Sekunde, bis Audio und Video synchron sind. Vielleicht funktioniert das interne syncen im Chip zu langsam, und deshalb macht es kodi selbst? Oder es gibt im Plugin noch Reste vom softhd*-Code zum syncen, die den Vorgang, der eigentlich in Hardware stattfinden soll, unnötig verlangsamen. Nur mal so als Theorie. Mir fehlen aber die Kenntnisse, um das im Code zu durchblicken.

    ACT-620, Asrock B75 Pro3-M, 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.

  • ja, das wirkt zumindest schneller. Ob es im Ergebnis tatsächlich ein Unterschied wäre, wenn das Bild noch solange schwarz bleiben würde, bis das Video zum Ton passt und weiterläuft, möchte ich aber noch nicht beschwören.


    Ich habe gestern und heute -nach der Änderung- ein paar Umschaltvorgänge geloggt. Das Tunen und Locken ist jedenfalls kein Zeitfresser. Vom Set Playmode 0 bis zur Meldung "pesdemux: pes start code id 0xbd" in PesParse() vergehen jeweils kaum 400 ms. Danach sind die Ergebnisse sehr unterschiedlich. Bis zur Meldung " first vpts" aus ProcessBuffer() vergehen weitere 400 bis 1400 ms.

    Beispiel (mit Deiner o.g.Änderung!)

    2022-06-14T12:12:33,836
    pesdemux: pes start code id 0xbd
    2022-06-14T12:12:33,838 00,002 in VideoDecode make close
    2022-06-14T12:12:33,838 00,000 CodecVideoClose Pip 0 Handle 46
    2022-06-14T12:12:33,854 00,016 internal close pip 0
    2022-06-14T12:12:33,859 00,005 AmlVideoSink - VIDEO/MPEG2
    2022-06-14T12:12:35,198 01,338 first vpts: 0x000defcc4e


    Die zweite Spalte gibt jeweils die Millisekunden an, die seit der in der darüber stehenden Zeile vergangen sind.

    Man müsste wahrscheinlich noch viel mehr debug-Meldungen einbauen, um das genauer analysieren zu können.

    ACT-620, Asrock B75 Pro3-M, 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.

  • Das Problem ist der Ton. Ich versuche in audio.c möglichst so viel Audio weg zu werfen bis der Audio PTS zum ersten Video PTS passt.

    Leider gelingt das nur schlecht. Schuld daran ist der Alsa Puffer den ich füllen muss um einen späteren Underflow zu vermeiden.

    D.h. ich muss Audio an ALSA geben damit der Puffer voll wird obwohl ich weiss das dieses Audio für das aktuelle Video Bild schon zu spät ist.

    Und dann ist der Video vorlauf auch bei jedem Umschalten noch anders, weil ich ja auch noch auf das erste I-Frame warten muss.


    Ich bin sicher das man hier noch optimieren kann. Nur ist das ein ziemliches gefummel und dann auch noch von der Hardware (CPU Speed) abhängig.

  • Machen das die anderen softhd*-Plugins genauso? Und dass es da fixer geht, liegt dann vermutlich an der stärkeren 'Motorisierung'?

    Wird denn ein eigener buffer im Plugin benötigt, oder haben bei amlogic Treiber/Hardware evtl. einen eigenen?


    Wäre toll, wenn Du da noch eine wie auch immer geartete Optimierung erreichen könntest.

    ACT-620, Asrock B75 Pro3-M, 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.

  • Du kannst mal /sys/class/tsync/slowsync_enable auf 1 setzen. Dann hast du wieder sofort Bild und dann wartet das Video auf den Ton.

    Das Umschaltverhalten wird damit nochmal etwas sauberer, wenn man in audio.c den Block

    entfernt. Das Audio kommt dann sehr früh, während das neue Bild sofort steht und nach einem kurzen Moment synchron weiterläuft. Andernfalls kommt es zu dem Effekt, dass das neue Bild nach dem Umschalten zunächst noch einen kleinen Moment läuft, ehe es stoppt und wieder weiterläuft.

    Mein Vorschlag wäre, /sys/class/tsync/slowsync_enable und diese Änderung als neuen Standard einzubauen.

    ACT-620, Asrock B75 Pro3-M, 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.

  • Wenn ich den Teil entferne und slowsync_enable auf 1 setze, dann bleibt das Bild zwar sofort stehen, aber dann dauert der sync so ca. 30 Frames. Mit dem Teil sind es "nur" ca. 12 Frames also deutlich schneller.


    Wenn du in ProcessClockBuffer den printf aktivierst dann siehst du wie er das AV Syncronisiert und wie gross der initial offset ist.


    Ich schaue mir das nochmal an, aber im Moment bin ich im Urlaub und habe kaum Zeit dafür.

  • Es kann sein, dass hier die reinen Messwerte und das subjektive Empfinden nicht übereinstimmen.

    Ich habe mal zwei Videos hochgeladen.

    mit dem o..g. Codeblock:


    meine Modifikation ohne den Codeblock

    Letzteres finde ich angenehmer. Der Ton kommt sehr früh, und das Umschaltverhalten wirkt m.E. angenehmer. Was meinen die anderen?


    In beiden Fällen habe ich übrigens das Schwarzbild beim Umschalten deaktiviert. Der Umschaltvorgang geht jetzt so schnell, dass das Schwarzbild eigentlich nur stört. Vielleicht können wir das als Option im Menü einstellbar machen, ebenso wie slowsync. Wieso das Aktivieren des slowsync nun allerdings das Umschalten schneller macht, bleibt etwas kurios... :/

    ACT-620, Asrock B75 Pro3-M, 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.

  • Vielleicht mal für den Test, beide Varianten einbauen und per Setup umschaltbar machen... ;) Somit könnte ich dieses mit den (fertigen) Images von Zabrimus auch testen... Bisher habe ich nur Du kannst mal /sys/class/tsync/slowsync_enable auf 1 setzen. umgesetzt und dies ist schon ein besseres Zapp-Verhalten...

  • jojo61

    ich wollte jetzt meine Scripte zum Zoomen des TV-Bildes auch auf meinem Odroid anwenden. Dazu hat Zabrimus das vdr-plugin-dbus2vdr eingebaut, damit man die Setup-Werte ändern kann.

    Mit dem "normalen" VDR-PC und dem softhddevice-Plugin klappt das perfekt. Siehe hier: [SOLVED] Zoomfunktion in Softhddevice


    Jetzt habe ich festgestellt, dass die Plugin-Parameter beim softhdodroid-Plugin dafür keinerlei Wirkung haben, egal welchen Wert ich reinschreibe:

    softhdodroid.1080i.CutLeftRight = 0

    softhdodroid.1080i.CutTopBottom = 0

    softhdodroid.1080i_fake.CutLeftRight = 0

    softhdodroid.1080i_fake.CutTopBottom = 0

    softhdodroid.576i.CutLeftRight = 0

    softhdodroid.576i.CutTopBottom = 0

    softhdodroid.720p.CutLeftRight = 0

    softhdodroid.720p.CutTopBottom = 0


    Ist das im softhdodroid-Plugin nicht mehr implementiert?

  • Ich habe auch mal mit dem Parameter /sys/class/tsync/slowsync_enable herumgespielt. Beim Live-TV ist zwar ein Unterschied; aber dieser ist für mich subjektiv minimal. Was ich jedoch festgestellt habe ist, dass das Spulen und Springen in Aufnahmen mit auf "1" gesetzten Wert deutlich flüssiger funktioniert. Ohne den Wert ist die Navigation durch die Aufnahme durch die Verzögerung bis zum Bild stark erschwert.

  • Ich habe auch mal mit dem Parameter /sys/class/tsync/slowsync_enable herumgespielt. Beim Live-TV ist zwar ein Unterschied; aber dieser ist für mich subjektiv minimal. Was ich jedoch festgestellt habe ist, dass das Spulen und Springen in Aufnahmen mit auf "1" gesetzten Wert deutlich flüssiger funktioniert. Ohne den Wert ist die Navigation durch die Aufnahme durch die Verzögerung bis zum Bild stark erschwert.

    Das erstaunt mich, denn ich habe diesbezüglich keinen Unterschied beim Spulen und Springen bemerkt. Das Springen geht verzögerungsfrei, nur das Spulen ist nicht ganz flüssig. Es werden anscheinend nicht alle Frames angezeigt, und alle paar Sekunden bleibt das Bild bei einem Frame stehen. Beim Rückwärtsspulen aktualisiert sich das Bild gar nicht, aber das war schon immer ein Problem auch bei den anderen softhd*-Plugins und mag auch vom Sender und der Aufnahme abhängen.


    Der Vorteil des slowsync_enable beim Umschalten bei Live-TV kommt erst richtig zur Geltung, wenn auch die von mir in #367 beschriebene Änderung reinkompiliert wird. Die wiederum macht das Umschalten ohne slowsync_enable aber schlechter.

    Ich habe jetzt mal einen Patch erstellt, der das Umschaltverhalten per OSD in den Plugin-Einstellungen konfigurierbar macht und einige Fixes enthält.

    • Die Einstellung "Fast channel switch" setzt /sys/class/tsync/slowsync_enable auf 1. Klingt paradox, hat aber nunmal diese Auswirkung. Diese Einstellung habe ich als Standard gesetzt (softhdodroid.FastSwitch = 1). Solange die Einstellung aktiviert ist (und nur dann), ist die oben in #367 beschriebene Änderung für die Audiosychronisation aktiv. Nach dem Umschalten bleibt das Bild kurz stehen, bis Bild+Ton zusammenpassen.
    • Die Einstellung "Black during channel switch" bleibt Standard (softhdodroid.BlackPicture = 1), kann aber deaktiviert werden. Dann bleibt das Bild beim Umschalten auf dem letzten frame stehen. Gefühlt geht das Umschalten so noch etwas fixer, aber das ist subjektiv und wird individuell sicher anders empfunden.
    • Beim Beenden von vdr (auch beim detachen) wird das Bild schwarz (sys/class/video/blackout_policy = 1) und /sys/class/tsync/slowsync_enable wird wieder auf 0 gesetzt. Damit sind die Treiber-default-Einstellungen wieder hergestellt und es sollte unter kodi keine Probleme geben.
    • Beim Umschalten (PLaymode 0) sollten eigentlich die buffer gecleart werden. Das funktionierte in SetPlayMode 0 aber bisher nicht, weil die Bedingung "if (MyVideoStream->ClearClose)" nie erfüllt war (ClearClose ist gar nicht mehr implementiert). Den direkten Aufruf von Clear() halte ich für unglücklich, da es eine vdr-interne Funktion ist, die für den Trickmode vorgesehen ist und immer das Stoppen auf dem letzten frame vorsieht. Deshalb habe ich nur Teile des gleichen Codes in SetPlayMode 0 ergänzt. Allerdings bin ich mir nicht sicher, ob das bezüglich Video überhaupt irgend etwas bewirkt: ClearBuffers soll CodecVideoFlushBuffers auslösen - diese Funktion ist in video.c aber leer. Zumindest die AudioBuffer sollten nun aber gecleart werden.
    • Den Sinn der Funktion amlReset() habe ich noch nicht ganz verstanden. Sie wird im Prinzip nur von Clear() und zur Fehlerbehandlung in SendCodecData() aufgerufen. Das Stoppen und Neustarten des Decoders findet aber auch ohne amlReset bereits beim Playmode 0 statt. Nach meinen Experimenten würde es reichen, beim Beenden einer Wiedergabe FirstVPTS = AV_NOPTS_VALUE; und isFirstVideoPacket = true; zu setzen. Einstweilen habe ich es mal so gelassen und lediglich die Behandlung der blackout_policy vereinfacht. Es reicht, sie hier auf 0 zu setzen. Der Wert 1 für ein Schwarzbild beim Umschalten wird über SetPlayMode 0 gesetzt bzw. als Standardwert beim Beenden zurückgesetzt. Das muss nicht jedesmal erfolgen, wenn man in einer Aufnahme springt.

    Kannst Du selbst kompilieren oder verwendest Du das image von Zabrimus ? Vielleicht kann er ja meinen Patch mal einbauen, damit mehr Leute das Testen können.

    Files

    ACT-620, Asrock B75 Pro3-M, 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.

  • Kannst Du selbst kompilieren oder verwendest Du das image von Zabrimus? Vielleicht kann er ja meinen Patch mal einbauen, damit mehr Leute das Testen können.

    Ich habe bisher nur die fertigen Images benutzt. Das Kompilieren hatte an zu vielen Stellen geklemmt. Muss ich bei Gelegenheit nochmal versuchen oder eben warten, bis es (optional) eingebaut ist.

  • zabrimus hat ja in seinem Thread geschrieben, dass er den Patch zur optionalen Verwendung integriert hat.

    ACT-620, Asrock B75 Pro3-M, 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.

  • Funktioniert das Plugin auch mit einem AmlogicS905Y2 ?

    Ich hab mal testweise den VDR von Zabrimus auf einem MagentaTV Stick installiert.

    Das OSD funktioniert. Allerdings bleibt das Video schwarz und es kommt nur der Ton.


    Im Log sehe ich immer wieder die Meldungen:


    Code
    1. Jun 23 09:26:11 CoreELEC kernel: 0: timeout_process decoder timeout, DPB_STATUS_REG 0xf0
    2. Jun 23 09:26:11 CoreELEC kernel: 0: vh264_work_implement, decode timeout flush dpb



    dmesg.txt

  • Gibt es neben dmesg ein syslog? dmesg enthält keine Meldungen von vdr bzw. seinen Plugins.

    Im Code von softhdodroid gibt es einen Check der Version:

    Die Frage wäre, welche Version da erkannt und geloggt wurde. Wenn der S905Y wie ein normaler S905 behandelt werden muss, aber wegen einer falschen Erkennung (vielleicht ist die Zuordnung im Plugin auch nicht korrekt) als S805 behandelt wird, könnte das die Probleme vielleicht erklären.

    Im Makefile ist CONFIG := -DDEBUG  standardmäßig aktiv, so dass die Debug-Ausgabe geloggt werden müsste.

    ACT-620, Asrock B75 Pro3-M, 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.

  • Bei mir bringt

    journalctl |grep 'AmlCodec: amstream version'
    die Ausgabe

    Jun 23 10:15:27 CoreELEC vdr[4050]: AmlCodec: amstream version : 2.0

    ACT-620, Asrock B75 Pro3-M, 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.