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

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.

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!)

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.

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.

Quote from jojo61

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

if (isRadio < 75) {    // do not wait forever if it is a Radio Station. Each Enque is 24ms Audio 
            
            vpts = FirstVPTS;

            if (vpts == AV_NOPTS_VALUE || AudioRing[AudioRingWrite].PTS == AV_NOPTS_VALUE) {
                usleep(1000);
                skip = n;   // Clear all audio until video is avail
            }
            else if ((unsigned long)AudioRing[AudioRingWrite].PTS  < vpts) {
                skip = n;    // Clear Audio until Video PTS
            } else  {
                int i = 10;
                while (SetCurrentPCR(0, (uint64_t)(AudioRing[AudioRingWrite].PTS - AudioBufferTime * 90 + VideoAudioDelay -24000 )) == 2 && i--) {
                    usleep(5000);
                }
            }
            isRadio++;
        }
        usleep(2000);

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.

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...

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.

Quote from heiko322

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.

Quote from Dr. Seltsam

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.

Wenn alles gut geht, dann sollten bis morgen früh neue Images gebaut worden sein. Die Images mit "-s" am Ende beinhalten den softhdodroid patch. Aber das dauert halt ein paar Stunden.

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:

Jun 23 09:26:11 CoreELEC kernel: 0: timeout_process decoder timeout, DPB_STATUS_REG 0xf0
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:

apiLevel = S805;

    int version;
    int r = ioctl(fd, AMSTREAM_IOC_GET_VERSION, &version);
    if (r == 0)
    {
        Debug(3,"AmlCodec: amstream version : %d.%d\n", (version & 0xffff0000) >> 16, version & 0xffff);

        if (version >= 0x20000)
        {
            apiLevel = S905;
        }
    }

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.

Bei mir bringt

journalctl |grep 'AmlCodec: amstream version'
die Ausgabe

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

journalctl |grep 'AmlCodec: amstream version'
Jun 23 10:23:33 CoreELEC vdr[3519]: AmlCodec: amstream version : 2.0

Hier einmal die journalctl:

journalctl.txt