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

Moin jojo61,

das softhdodroid-Plugin läuft sehr stabil und ermöglicht einen VDR im Praxisbetrieb. Vielleicht kannst Du Dir bei Gelegenheit nochmal eine Baustelle ansehen, die im Vergleich mit anderen softhd-Plugins noch etwas unrund läuft:

Das Spulen -also der schnelle Bildsuchlauf- innerhalb von Aufnahmen funktioniert bei mpeg2 vorwärts und rückwärts einwandfrei. Bei h264 funktioniert es jedoch nur vorwärts. Rückwärts aktualisiert sich das Bild nicht. Bei meinem VDPAU-basierten VDR klappt das Spulen -mit ganz wenigen Ausnahmen- auch rückwärts. Kodi kann h264 auf meinem Odroid N2+ auch rückwärts abspielen, es muss also grundsätzlich 'irgendwie' gehen.

Der Wechsel von Wiedergabe zu Pause (Standbild) und zurück funktioniert einwandfrei. Wählt man aus der Pause heraus die Zeitlupenfunktion, beschleunigt sich das Bild zunächst, ehe die Zeitlupengeschwindigkeit kommt. Beim Wechsel von Zeitlupe zu Play dann wieder der gleiche Effekt, die Aufnahme läuft erstmal ein Stück in schneller Geschwindigkeit vorwärts. Ich habe den Verdacht, dass es mit der Audio/Video-Synchronisation zu tun hat, denn die für einen Moment zu schnell laufenden Bilder kommen ja auch manchmal nach dem Umschalten.

Weisst Du ansonsten, was

AMSTREAM_IOC_SET_FREERUN_MODE

AMSTREAM_IOC_TRICKMODE (aktuell nicht verwandt)

konkret bewirken?

Nachtrag: wenn man in den vdr-Einstellungen die Sprungweite mit Taste gelb/grün bei Wiederholung auf z.B. 2s oder 5s Sekunden einstellt und dann die grüne Taste dauerhaft gedrückt hält, passiert im Prinzip genau das, was auch beim Rückspulen passieren soll. Prinzipiell hat der Dekoder also kein Problem mit der Wiedergabe von Paketen, deren PTS rückwärts läuft.

Quote from jojo61

Das Problem hier ist das ich den Videopuffer im Kernel nicht löschen kann und der ist noch von der Zeitlupe verstopft.

Im Code sind ja AMSTREAM_CLEAR_VBUF und AMSTREAM_IOC_CLEAR_VIDEO in auskommentierten Funktionen enthalten. Hattest Du die mal ausprobiert?

Das Leeren der Puffer gehört m.E. in SetPlaymode für case 0 (pmNone). Ich werde das morgen sonst mal probieren.

Ich habe zunächst mal versucht herauszufinden, wo/an welcher Stelle die Hardware-Buffer derzeit überhaupt gecleart werden. Grundsätzlich muss das eigentlich der Fall sein, sonst würde man beim Umschalten noch Reste des alten Bildes sehen und auch Spulen/Springen innerhalb von Aufnahmen würde nicht richtig funktionieren.

Das ganze Plugin ist leider wegen der Übernahme der Grundstruktur von Gottvater johns etwas unübersichtlich. So ganz schlau werde ich nicht aus dem Code, sehr viel toter Code, der überhaupt nichts bewirkt.

MyVideoStream->ClearBuffers verweist auf CodecVideoFlushBuffers - diese Funktion ist im Plugin aber leer!

VideoSetClosing setzt decoder->Closing = 1. Wieder finde ich keinen Code, der daraufhin irgendetwas bewirkt, was die Hardware-Buffer cleart.

Das Stoppen und Clearen des Decoders erwartet vdr eigentlich an 2 Stellen - einmal in SetPlayMode(pmNone), und einmal in Clear(). Der Unterschied ist eigentlich nur, dass im ersten Fall das Bild auf dem letzten Frame schwarz wird und im 2. Fall (da für Trickmode genutzt) auf dem letzten Frame stehen bleiben soll.

Was mir auffiel ist, dass amlReset nur in Clear() aufgeführt wird, aber nicht bei pmNone. Ersetzt man den Code in Clear() gegen den aus pmNone und ändert nur die blackout-policy auf 0, funktioniert Clear scheinbar genauso gut auch ohne amlReset. Aber wie gesagt, wodurch dann eigentlich gecleart wird konnte ich nicht ermitteln.

Wird nach einer Pause (Freeze) wieder Play gewählt, ruft vdr gar keinen Clear auf. Nur wenn aus der laufenden Wiedergabe heraus der schnelle Bildsuchlauf gewählt wird, wird vor dem Aufruf von TrickSpeed ein Clear angefordert. Ebenso beim Wechsel zurück auf Play.

Anders ist es bei der Zeitlupe. Sowohl beim Wechsel von Freeze zu einer langsamen Trickspeed als auch von dort zurück in Play wird von vdr kein Clear angefordert. Grundsätzlich dürfte es auch gar nicht notwendig sein, dort einen Buffer zu clearen - softhddevice macht das genauso wenig wie andere Hardware-Ausgabeplugins.

Ich habe testweise in diesen Fällen (also Wechsel von Speed 2, 4, 8, 24, 48 oder 63, was Slow Motion ist, zurück auf 0=normal) dennoch einen Clear ausführen lassen. Dann beschleunigt das Bild zwar nicht mehr, aber es erfolgt ein kleiner Sprung, so dass Inhalt verlorengeht. Das ist auch nicht akzeptabel. Mir ist nicht klar, warum das überhaupt passiert, denn aufgrund der über GetSTC() ermittelten PTS sollte man wieder exakt an der richtigen Position landen. Beim Spulen (Speed 3, 6 oder klappt das ja auch.

Das Problem zeigt sich ansonsten auch in PlayVideo3():

// hard limit buffer full: needed for replay
    if (atomic_read(&stream->PacketsFilled) >= VIDEO_PACKET_MAX - 10) {
        // Debug(3, "video: video buffer full\n");
        usleep(20000);
        return 0;
    }

An dieser Stelle läuft der Buffer sofort über, wenn man aus der Pause heraus die Zeitlupe aktiviert. Aber warum?

Ich habe an dieser Stelle AMSTREAM_CLEAR_VBUF und AMSTREAM_IOC_CLEAR_VIDEO ausprobiert. Das erste hat keine Wirkung, das zweite führt nur zu einem Flackern des Bildes.

Mir ist nicht ganz klar, wieso das überhaupt zu einem Problem führt. Durch das return 0 wird die Funktion ja beendet und es werden keine weiteren Videodaten an den Decoder weitergereicht. Trotzdem bekommt der offenbar mehr Videodaten als dazu zeitlich passende Audiodaten, d.h. der Ton würde hinterherlaufen. Da es für diesen Fall bei der A/V-Synchronisation anscheinend keine Lösung (Verwerfen der Videopakete) gibt, spielt die Hardware die Videopakete dann solange schneller ab, bis sie wieder zum Ton passen. Das wäre jetzt mein Versuch einer Analyse...

Hi,

Das kenne ich aber von Softhddevice (alte Version von lnj) auch seit Jahren (in easyvdr 2.5 und 3.5 sowie v5) .

MfG Stefan

Quote from jojo61

Ich habe es nun doch mal in den Treiber eingebaut und mich am Abstand der I-Frames bei MPGE2 orientiert. Da sieht das bei H264 etwas besser aus, aber irgendwie ist es immer noch nicht wie bei mpeg2. Das liegt dann wohl wirklich am Abstand der I-Frames. Was ich gesehen habe ist das der vdr manchmal beim spulen unbedienbar wird und nicht mehr auf Eingaben reagiert.

mfg

Jojo61

Hi, aber spulen / Zeitlupe rückwärts geht damit auch bei Dir noch nicht, oder? Vorwärts geht, nicht perfekt, aber geht. Nur geht bei mir leider zurück spulen genauso wenig wie Zeitlupe rückwärts. Wenn das ginge, fliegt der Intel VDR raus und der Odroid N2+ übernimmt

Insofern kann ich auch hier nur nochmal Danke an alle sagen, die immer noch an diesem genialen Stück Software mitwirken!

Space

Ich kann leider auch überhaupt keine Verbesserung erkennen. Im Gegenteil, aus der Zeitlupe, die vorher in der niedrigsten Geschwindigkeit zumindest eine korrekte Einzelbildfortschaltung war, ist jetzt ein langsamer Bildsuchlauf geworden.

Rückwärts spulen geht bei h264 weiterhin nicht.

Ist das vlt. auch noch Sender-abhängig? Ich habe mit Tagesschau von ARD HD getestet ...

EDIT: und als Info zur Software: ich bin auf der aktuellsten VDR*ELEC von Zabrimus, die hat softhdodroid in Version 3.85. (bzw. auf c598ae547d3f50d0feda108f9b783ea300ad6539 um genau zu sein).

Kannst Du mal eine h264-Testaufnahme, bei der das Zurückspulen bei Dir klappt, irgendwo hochladen? Von meiner ARD-Aufnahme, bei der es nicht geht, werde ich heute Abend auch einen Ausschnitt bereitstellen.

Quote from jojo61

Das ist die aktuelle Version. Ich denke schon das es vom Sender ahängig ist da jeder einen anderen I-Frame zyklus haben kann. Aber es sollte keinen unterschied machen da ich ja die PCR differenz berücksichtige. Hast du MultiSpeed aktiv ?

MultiSpeedMode = 1

Ja ... ich habe gerade auch nochmal getestet und *laaaaange* zurückspulen lassen. Nachdem er laut Zeitanzeige 2-3m zurückgespult hatte, kam mal wieder ein neues Bild, dann wieder ein paar Minuten gar nichts ...

Habe gerade auch nochmal zur Probe eine Aufnahme vom ZDF gemacht ... da kann ich zurückspulen ... kannst Du evtl. auch mal mit der Tagesschau um 20:00 testen, ob Du da bei Dir zurückspulen kannst? Sonst stell ich einen Ausschnitt der Tagesschau zur Verfügung, wo es bei mir nicht geht.