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?

    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

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

    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

  • Im FREERUN _MODE wird kein PTS ausgewertet. So wie ich das ermittelt habe werden da die Frames einfach angezeigt so wie sie kommen. Allerdings muss man hier wohl immer nur I-Frames schicken damit sie angezeigt werden, weil Rückwärts ja die Referenzen für andere Frametypen nicht vorhanden sind.
    Da die dekodierung komplett im Kernel bzw. auf der Hardware ablaufen habe ich da wenig einflussmöglichkeiten und ich war froh das das Spulen überhaupt funktioniert. Ich schaue es mir aber nochmal an ob man es verbessern kann.


    Der wechsel von Zeitlupe zu Play ist immer mit einer neusyncronisation zum Audio verbunden. Das funktioniert leider nicht immer so wie ich es gerne hätte und dann rennt das Bild bis es den Ton eingeholt hat. Das Problem hier ist das ich den Videopuffer im Kernel nicht löschen kann und der ist noch von der Zeitlupe verstopft.

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

    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 damit rumgespielt, hatte aber den Eindruck das es nichts bewirkt. Aber du kannst gerne selber mal testen :) Für Feedback bin ich immer dankbar.

    Meine tests waren damals aber auch noch auf dem Odroid kernel und nicht auf dem Corelelec Kernel, vielleicht ist es ja nun anders.

  • 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 8) klappt das ja auch.


    Das Problem zeigt sich ansonsten auch in PlayVideo3():

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

    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

  • Hallo

    ich sehe du bist tief in die Problematik eingestiegen und an den gleichen Stellen gelandet die auch mir Sorgen bereiten. Ich sehe hier mehrere Probleme die nicht auber gelöst sind. Zum einen wird der aktuell angezeigte PTS vom Kernel wohl nicht sauber zurück geliefert (zumindest erscheint mir hier ein Slack zu sein). Dann gibt es ja auch noch im ALSA Treiber einen Puffer (der wird zwar versucht zu berechnen aber das funktioniert auch nur bedingt gut).

    Und zu guter Letzt sendet der vdr die Videodaten in unbegrenzter Geschwindigkeit wenn er eine Aufnahme abspielt. Deswegen gibt es z.b. in PlayVideo3 den Hard Limit der dann sofort voll läuft wenn man das video nur in Zeitlupe ausgibt.

    Um sauber vor und zurückspulen zu können müsste der VDR beim spulen zumindest erstmal auf I-Frames schalten. (könnte sein das er das schon tut, nur ist es mir bisher noch nicht so vorgekommen). Die Zeitlupe wird nun dadurch realisiert das ich in CodecVideoDecode einen sleep einbaue bei TrickSpeed. Das ist definitiv eine Dirty Lösung, nur mir ist nix besseres eingefallen um der Stream zu bremsen.

  • Dr. Seltsam

    Ich habe mir das nun nochmal angesehen und der VDR sendet tatsählich nur I-Frames beim spulen. Dazu wird dann Trickspeed gesetzt um anzuzeigen wie oft das Frame wiederholt werden soll. Bei MPEG2 funktioniert das auch ganz nett. Aber bei H264 sind die I-Frames doch recht weit auseinander und da rennt dann das Bild sehr schnell. Grund hierfür ist das Trickspeed auf 1 sitzt wenn man kein Multi Speed aktiviert hat. Mit aktiven Multispeed sieht es besser aus weil da Trickspeed mit 6 anfängt (d.h. jedes I-Frame wird 120ms angezeigt) und damit ergibt sich eine sinnvolle Zeitlupe.

    Eigentlich müsste Trickspeed an die Frequenz der I-Frames angepasst werden. D.h. bei Mpeg2 anders als bei h264 sein, wenn man die gleiche Zeitlupe oder Zeitraffer haben will. Das ist aber nicht der Fall. Ich könnte das nun in den Treiber einbauen, aber ich denke das wäre besser im VDR Kernel aufgehoben.

  • 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,

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

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

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

    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

  • Hmm das ist seltsam. Bei mir geht das durchaus. Vor und Zurück. Wichtig ist das ihr Multi speed aktiv habt.

    Im Prinzip ist es ganz einfach. Der VDR schickt I-Frames und sagt wie lange sie zu wiederholen sind. Daran habe ich auch nichts geändert. Ich habe nur die Wiederholzeit zusätzlich von der Differenz des PCR Values zwischen den I-Frames abhängig gemacht. An der Zeitlupe Rückwärts könnte man noch verbessern weil da der VDR sehr hohe wiederholzeiten (Trickspeed values) vorgibt.


    Das ganze wird in CodecVideoDecode gemacht. Wenn ihr da etwas verbessern könnt nehme ich Feedback gerne an.

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

  • 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 ?

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

    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

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

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!