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

  • jojo61

    Danke für die neue Version vom softhdodroid-Plugin.

    Das Zoomen klappt nun sofort, brauche also nicht mehr einen Senderwechsel. Super. :thumbup:


    Was leider nicht so optimal ist, das nun der Codec "MPEG-2 , MPEG-4 , H.265" an Stelle der Bildauflösung "576i , 720p , 1080i , UHD" verwendet wird.


    Da muss ich mir noch was einfallen lassen, wie ich das optimal machen kann, damit das zoomen richtig klappt.

    Momentan mit den softhddevice-Plugin hatte ich es ja so gelöst, wenn ich z.B. um 10% aufzoomen will:




    Jetzt beim softhdodroid-Plugin habe ich das Script erstmal so gemacht:


    Code
    1. ### Zoom = 10% ###
    2. /usr/local/bin/vdr-dbus-send.sh /Setup setup.Set string:"softhdodroid.MPEG-2.CutLeftRight" variant:string:"51"
    3. /usr/local/bin/vdr-dbus-send.sh /Setup setup.Set string:"softhdodroid.MPEG-2.CutTopBottom" variant:string:"29"
    4. /usr/local/bin/vdr-dbus-send.sh /Setup setup.Set string:"softhdodroid.MPEG-4.CutLeftRight" variant:string:"96"
    5. /usr/local/bin/vdr-dbus-send.sh /Setup setup.Set string:"softhdodroid.MPEG-4.CutTopBottom" variant:string:"54"
    6. /usr/local/bin/vdr-dbus-send.sh /Setup setup.Set string:"softhdodroid.H.265.CutLeftRight" variant:string:"192"
    7. /usr/local/bin/vdr-dbus-send.sh /Setup setup.Set string:"softhdodroid.H.265.CutTopBottom" variant:string:"108"



    Das ist aber leider nicht immer richtig, denn der Codec "MPEG-4" kann ja zum einen 1280x720 oder auch 1920x1080 Pixel sein.

    Und somit ist ein Zoom um 10% dann einmal 64x36 oder dann auch 96x54 Pixel.

    Aber ich habe ja nun keine Unterscheidung mehr, welche Bildauflösung gerade verwendet wird. Also 720p wie bei den ARD- bzw. ZDF-Sendern oder eben 1080i wie bei den privaten HD-Sendern, denn beides ist ja "MPEG-4". :(

    Und somit zoome ich bei 720p viel mehr als 10%, d.h. ich muss da noch einen Mittelweg finden! ;)


    Aber Hauptsache es funktioniert überhaupt erstmal und ich kann zoomen, um die leidigen schwarzen Balken oben und unten wegzubekommen. ;)

    Da werde ich etwas experimentieren, um die optimalen Zoomfaktoren zu bekommen.

    The post was edited 1 time, last by Paulaner ().

  • Super, das werde ich demnächst testen und in mein Script einbauen! :thumbup:

    Es genügt dabei ja nur /sys/class/video/frame_width auszulesen, denn damit ist der Rest ja auch klar! ;)


    UPDATE:

    Habe mein Script um die Abfrage cat /sys/class/video/frame_height erweitert und nun klappt es einwandfrei! Perfekt! :) :thumbup:

    Vielen Dank nochmals für Deine Hilfe und den Tipp mit der Abfrage der Bildparameter.

    The post was edited 4 times, last by Paulaner ().