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

  • Tja, da bin ich auch überfragt. Empfangsprobleme kannst Du ausschließen? Was ist Deine iptv-Quelle? Sind die Einträge der channels.conf korrekt?

    Ein DVB device hast Du ja nicht

    Diese timeout-Kernelmeldungen vom Decoder habe ich jedenfalls nicht.


    Dieter schrieb in VDR auf 40€ TV-Box - Tanix TX3 und ähnlichen Amlogic basierten Boxen

    Quote

    Den S912 sollte man meiden, ebenso die anderen Varianten with S905X4, X2, X, W und L.

    Den S905Y erwähnt er nicht, aber vielleicht weiss er mehr

    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.

  • Empfangsprobleme kann ich ausschließen. Das ist IPTV mit MagentaTV von hier. Die Channels.conf funktioniert auch am anderen VDR.

    Hab gerade die VDR Aufnahmen per NFS eingebunden und beim Abspielen von Aufnahmen das gleiche Problem. Ich kann aber auch nur H264 Sender/Aufnahmen testen.


    Gruß dile

  • tja, da habe ich keine Idee. Vielleicht kann jojo61 nach seinem Urlaub mal schauen, ob andere Programme wie kodi für den S905Y besonderen Code verwenden.

    Amlogic ist leider mehr oder weniger undokumentiert.

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

    Ich konnte ein Image mit den softhdodroid patch testen. Das Umschalten ist tatsächlich noch etwas flotter und liegt jetzt bei so etwa 1 Sek. Das Springen in Aufnahmen und der Vorlauf funktionieren auch einwandfrei. Ansonsten konnte ich keine Fehler feststellen.

    Ein Problem habe ich noch bei Rückwärtsspulen in HD-Aufnahmen. Da bewegt sich nur der Anzeigebalken, aber das Bild bleibt stehen. Das ist aber unabhängig vom Patch und bereits zuvor aufgetreten. Ist das ein bekanntes Problem oder nur bei mir so?

  • Ja, das ist auf alle Fälle noch eine Baustelle. Ich zitiere mich aus #373:

    Quote

    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

    Ich habe noch nicht ganz verstanden, wie das Spulen überhaupt umgesetzt wird. Der Amlogic Treiber scheint nicht selbst verschiedene Abspielgeschwindigkeiten per ioctl zu unterstützen, sondern nur einen allgemeinen Trickmode.

    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.

  • Ich habe es jetzt mal mit einer mpeg2-Aufnahme (SD RTL) getestet. Dort klappt das Spulen vorwärts und rückwärts einwandfrei. Man sieht die einzelnen Frames und es läuft flüssig. Das Problem scheint nur bei h264 zu existieren. Wobei ich bisher nur 720p getestet habe. Muss mal suchen, ob es frei empfangbare 1080i Sender im Kabel gibt.

    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 ist leider "noch" nicht implementiert. Als ich den Treiber entwickelt habe dachte ich das es gar nicht geht. Das decodieren macht ja der Kernel und ich sehe das fertige Frame nie. Zwischenzeitlich habe ich aber gesehen das es wohl doch Kernelparameter gibt die ein crop ermöglichen. Ob das aber dann damit funktioniert muss ich noch ausprobieren. Wenn es geht dann baue ich es ein.


    Dr. Seltsam Ich habe mir deinen Patch angesehen und werde ihn einbauen. Ich will es aber vorher nochmal testen. Komme aber erst am Montag dazu.

    Schonmal danke für deine Mühe.

  • jojo61 Kannst Du Dich erinnern, warum Du in VideoSetTrickspeed den speed-Wert auf 6 begrenzt hast?

    Code
    1. if (speed > 6)
    2. speed = 6;

    Das macht m.E. keinen Sinn.

    die device.h von vdr beschreibt

    So wie es ist, kann die Zeitlupenfunktion also nur vorwärts in Stufe 2 und 3 richtig funktionieren.

    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.

  • Ich habe nun den Patch von Dr.Seltsam eingecheckt. Allerdings habe ich den default von FastSwitch auf false gesetzt.


    Trickspeed ist schwierig weil ich dem Treiber nicht sagen kann wie schnell er abspielen soll. Also verzögere ich die Frames bei TrickSpeed.

    Dabei habe ich ehrlich gesagt nicht an die Zeitlupe gedacht.

  • jojo61 danke für die schnelle Umsetzung meines Wunsches.

    Ich werde es testen und berichten sobald Zabrimus es in seinen Images aktualisiert hat! ;)

  • jojo61 : magst Du das noch einchecken:


    es entfernt lediglich die falsche Begrenzung auf speed 6. Der Rest ist Formatierungskorrektur.

    Alle Geschwindigkeiten funktionieren, sowohl FF/REW als Zeitlupe vor und zurück.


    Bei der Zeitlupe gibt es noch das Problem, das nach dem Wechsel vom Standbild zur Zeitlupe vorwärts das Bild erstmal ein Stück schnell vorwärtsläuft, ehe die langsame Zeitlupe beginnt. Das untersuche ich noch.

    Und bei h264 funktioniert die Bildaktualisierung beim Rückwärtslauf nicht. Letzteres könnte vielleicht daran liegen, dass in PesParse einiger h264-spezifischer Code fehlt, der an der Stelle in softhddevice vorhanden ist.

    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.

  • So ich habe nun auch das crop eingebaut. Leider geht das nur per Codec und nicht mehr per Auflösung.

    Ich habe es getestet und prinzipiell läuft es erstmal. Das Bild wird gezoomt, wenn man die Werte für softhdodroid.xxx.CutTopBottom bzw. softhdodroid.xxx.CutLeftRight ändert.


    Ob das jetzt mit den "codec-Variablen" auch so funktioniert wie vorher muss ich nochmals in Ruhe testen.

    Denn damit das Bild gleichmäßig gezoomt wird, ohne das z.B. Eierköpfe entstehen, muss man ja die Werte für Oben/Unten und auch für Links/Rechts entsprechend der aktuellen Auflösung prozentual richtig ändern.


    Allerdings muss ich jetzt immer einmal den Sender wechseln, damit der geänderte Zoom aktiv wird. ?(

    Vorher hat das auch ohne Senderwechsel funktioniert. siehe hier! Da klappte es durch neu zeichnen des Bildes.

  • Allerdings muss ich jetzt immer einmal den Sender wechseln, damit der geänderte Zoom aktiv wird

    Ja ich dachte mir schon das dich das stören wird. Ich werde das noch ändern damit es sofort passiert. Da ich die Frames nicht mehr sehe müsste ich bei jeden Frame das crop an den Kernel schicken. Das möchte ich nicht. Ich werde nun einbauen das dies nur geschieht wenn sich das crop ändert.


    Leider ist mir vor 2 Tagen bei einem Gewitter mein Entwicklungsrechner kaputt gegangen und ich kann derzeit nichts einchecken. Ich kann erst nächste Woche wieder normal arbeiten :-(

  • jojo61 wäre super, wenn Du das noch bei Gelegenheit ändern könntest. Eilt aber nicht so sehr! ;)