[ANNOUNCE] HD Ausgabeplugin für Raspberry Pi, Version 1.0.0

  • Oh. Hab gerade nachgesehen und gemerkt das 'tvservice -s' mir ausgibt das CEA20 eingestellt ist. Also 1920x1080i. Meine Frau sieht gerade Fern. Werde es später mal umstellen und sehen was dann passiert. Danke erstmal für den Tipp.

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;) *


    vectra --- glasslike ---

  • Hallo Thomas,


    Quote

    Das wäre technisch zwar machbar aber IMHO völliger Quatsch. Besser sollte man versuchen, das Problem bei Skindesigner zu lösen.

    Meiner Meinung nach ist das kein Skindesigner Problem. Lass mich aber gerne eines Besseren belehren.


    Das Problem tritt nur auf wenn der Advanced-Interlacer aktiv ist. Bei HD Kanälen gibt er keine Probleme.


    Ich glaube der RPI ist schlicht überfordert den Advanced-Interlacer und das Scrolling oder Fading im OSD dar zu stellen.


    Von daher glaube ich ist mein Lösungsvorschlag nicht so schlecht.


    Hat den sonst niemand das beobachten können?

  • I wonder, what skins are you using with rpihddevice in general. I have 4 raspberries, and I haven't seen any advantage "stressing" them with complex skins, like skindesigner. Skindesigner needs more resourses than the whole vdr + streamdev-client + satip + rpihddevice.
    3 on my raspberries (rpi 1 A, rpi 1B and rpi 3B) I'm using "simple" skins like skinsoppalusikka and/or skinenigmang, and only on my rpi 2B I'm using a very outdated skindesigner with the most simple skin (metrixhd), as I made some customizations to it, like displaying a temperature graph which is helpful for me. In other aspects I see no advantage using complex skins.

    Server: Celeron J1800M-D3P, 6x DVB-S2 adapter, 6x Inverto quad LNB.
    Client 1: RPi 2 model B, rpihddevice, Sharp 42" LC40LE600, Client 2: RPi 1 Model B, rpihddevice, Asus Led HD monitor, Client 3: RPi 1 Model A, rpihddevice, CRT TV, Client 4: RPi 3, rpihddevice, in test.
    VDR user since: 2005-11-27 (#1199)

  • Meiner Meinung nach ist das kein Skindesigner Problem. Lass mich aber gerne eines Besseren belehren.


    [...]


    Ich glaube der RPI ist schlicht überfordert den Advanced-Interlacer und das Scrolling oder Fading im OSD dar zu stellen.


    Ich habe mir kurz den Code von Skindesigner angeschaut. Die Animationen laufen alle mit 50fps, was natürlich schon eine ordentliche Hausnummer ist. Umso mehr, wenn man bedenkt, dass bei mehreren Objekten die Animationen parallel ablaufen.


    Ich frage mich, ob inzwischen nicht einfach die Erwartungen etwas aus dem Ruder gelaufen sind... Natürlich funktioniert sowas problemlos mit einer Desktop-CPU, aber auf einem 35$-Kleincomputer mit einer TDP von ~5W hat nun halt auch die GPU gewisse Grenzen und erfordert einen massvollen Umgang mit den vorhandenen Ressourcen. Nichts gegen das skindesigner-Plugin - ich finde, louis macht hier tolle Arbeit - aber parallele Einblendeffekte mit jeweils 50fps halte ich schon für problematisch.


    Gruss
    Thomas

  • Hallo Thomas,


    Ich frage mich, ob inzwischen nicht einfach die Erwartungen etwas aus dem Ruder gelaufen sind... Natürlich funktioniert sowas problemlos mit einer Desktop-CPU, aber auf einem 35$-Kleincomputer mit einer TDP von ~5W hat nun halt auch die GPU gewisse Grenzen und erfordert einen massvollen Umgang mit den vorhandenen Ressourcen. Nichts gegen das skindesigner-Plugin - ich finde, louis macht hier tolle Arbeit - aber parallele Einblendeffekte mit jeweils 50fps halte ich schon für problematisch.

    Ich geb dir schon Recht, dass man von einem RPI nicht allzu viel erwarten sollte. Die GPU hat sicher Grenzen, die in diesem Fall wohl erreicht sind.
    Nur bisher hat alles smooth funktioniert. Sogar simultane Scrollings und Einblendungen. Nur seit dieser Advanced-Interlacer im Einsatz ist stockt es leider.


    Nun kann man sagen, man sollte das OSD so machen das es mit dem Advanced-Interlacer klar kommt. Dann ist aber der Einstaz von Skindesigner mit "metrix" - Skin nur noch bedingt möglich. Denn ruckelt faktisch alles was mit Bewegung zu tun hat.
    Für mich wäre halt das TV-Bild bei Betrachten des OSDs nicht das wichtigste. Heist hier könnte der Advanced-Deinterlacer abgeschaltet werden.


    So hätte man beim OSD auch noch Reserven für andere "Spielereinen" übrig und steht nicht am Limit.


    Vielleicht wäre dieser Lösungsweg ja über Schalter möglich?


    Verstehe mich bitte nicht falsch, ich möchte mich nicht in deine Entwicklung einmischen.


    Aber bisher liefe alles super rund und ich möchte ja nicht bei dem Commit ohne Advanced-Deinterlacer stehen bleiben oder den Skindesigner deinstallieren.


    VG Uli

  • Ich geb dir schon Recht, dass man von einem RPI nicht allzu viel erwarten sollte.


    Nein, darum geht es nicht. Aber der verschwenderische Umgang mit Ressourcen ist in meinen Augen keine Schwäche des Raspberry Pis! Bitte überleg dir mal, was vor der Einführung des beschleunigten High-Level-OSDs möglich war und wo wir heute stehen. Mit dem Hintergrund finde ich deine Aussage schon fast respektlos.


    Vielleicht wäre dieser Lösungsweg ja über Schalter möglich?


    Das dynamische Umschalten des Deinterlacers, wenn das OSD eingeblendet wird? Vergiss es.


    Gruss
    Thomas

  • Mit dem Hintergrund finde ich deine Aussage schon fast respektlos

    Also bitte, du weißt wie ich das gemeint hab.

    Das dynamische Umschalten des Deinterlacers, wenn das OSD eingeblendet wird? Vergiss es.

    Ok, vielleicht kannst ja dann das grundsätzliche Abschalten des Adanced Deinterlacers einbauen...


    Ich werde auf jeden Fall mal Louis frage ob man an den 50 fps für Animationen was machen kann und wie groß der Aufwand ist.


    VG Uli

  • Oh. Hab gerade nachgesehen und gemerkt das 'tvservice -s' mir ausgibt das CEA20 eingestellt ist. Also 1920x1080i. Meine Frau sieht gerade Fern. Werde es später mal umstellen und sehen was dann passiert. Danke erstmal für den Tipp.


    Hi Thomas.
    Lag definitiv nicht an dir. Hatte es wohl mal in den Plugin Einstellungen auf 50i umgestellt. Warum auch immer :rolleyes:
    Jetzt sieht es wieder besser aus. Danke für den tipp.

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;) *


    vectra --- glasslike ---

  • Moin,

    Ich werde auf jeden Fall mal Louis frage ob man an den 50 fps für Animationen was machen kann und wie groß der Aufwand ist.


    klar kann man da was machen, hier sind die fps definiert. Könnt ihr ja mal mit anderen Werten spielen und testen, wie es sich dann verhält.


    Ciao Louis

  • Hallo,


    Könnt ihr ja mal mit anderen Werten spielen und testen, wie es sich dann verhält.


    Das hatte ich gerade. Mit 25 keine spürbare Änderung, selbst mit 5 (fünf) stockt das Bild, wenn man durch die Schedules zappt und beim Currentelement das Fading aktiviert hat. Abgesehen davon, dass man bei 5FPS nicht mehr von Fading sprechen kann.


    Ich sehe das pragmatisch, Fading im Skin auf NULL und gut ist's ;) oder andere Hardware nutzen...


    Gruß,
    Tomas

  • Hallo thomas,

    Ich sehe das pragmatisch, Fading im Skin auf NULL und gut ist's ;) oder andere Hardware nutzen...

    Ich seh's nicht ganz so pargmatisch.


    1) Es betrifft auch andere Stellen, wie z.B. das Scrolling von Text
    2) Insgesamt scheint das OSD langsamer zu sein
    3) Wenn ich Parameter im Sourcecode von skindesigner ändere muss ich bei jden Update diese mitziehen.


    Und ehrlich gesagt möchte ich auf keinen Fall eine andere Hardware einsetzen. Der RPI2 war bisher super performant.


    VG Uli

  • Moin,

    2) Insgesamt scheint das OSD langsamer zu sein


    naja, die Tests von Tomas zeigen wohl, dass die GPU mit dem "advanced Interlacer" mehr oder weniger voll am Anschlag ist. Dann ist es kein Wunder, dass das OSD langsamer wird, da die Darstellung des OSD per GPU ja auch ein paar freie Slots braucht.


    Ohne da jetzt wirklich die Internas zu kennen, wage ich mal die Aussage, dass dieser "advanced Interlacer" von den Raspi Leuten noch nicht ganz optimal implementiert ist. Dass der die GPU so zum Anschlag bringt, darf eigentlich nicht sein.


    Ciao Louis

  • Die Verwendung des Advanced-Deinterlacers ist nun im Plugin-Setup konfigurierbar, ich habe die Änderung soeben in git eingecheckt.


    Zusätzlich gibt es eine neue Debug-Option: Mit "make DEBUG_OVGSTAT=1" übersetzt gibt das Plugin laufend die Anzahl ausgeführter OpenVG-Kommandos und OSD-Flushes der letzten Sekunde aus. Damit lässt sich die Last der GPU zumindest etwas abschätzen.


    Gruss
    Thomas

  • Hallo Thomas,
    hier gibt es mit dem aktuellen Plugin (git) (und der aktuellen Firmware für den Pi (vor 5min upgedatet)) ein crash, wenn ich auf ein 1080i Sender z.B. ServusTV HD schalte.
    Ist der erweiterte Deinterlacer eventuell auch bei HD aktiv? Meine Einstellung ist: "nur bei SD"
    Wenn ich den Deinterlacer deaktiviere, gibt es kein Crash bei Servus TV HD.


    Ansonsten läuft es sehr stabil in letzter Zeit, vielen Dank dafür Thomas. :)


    Sieht im Log wie folgt aus:

  • Hallo Uwe


    hier gibt es mit dem aktuellen Plugin (git) (und der aktuellen Firmware für den Pi (vor 5min upgedatet)) ein crash, wenn ich auf ein 1080i Sender z.B. ServusTV HD schalte.

    Gemäss deinem Log geht der GPU der Speicher aus. Das ist grundsätzlich denkbar, da der Speicherbedarf der GPU mit den letzten Firmware-Updates ein klein wenig gestiegen ist.


    Ist der erweiterte Deinterlacer eventuell auch bei HD aktiv? Meine Einstellung ist: "nur bei SD"
    Wenn ich den Deinterlacer deaktiviere, gibt es kein Crash bei Servus TV HD.

    Sollte er zumindest nicht, ausser du hast die Einstellung auf "immer" stehen. Kannst du das Problem auch nach einem Neustart nachvollziehen, oder gibt es evtl. Speicherleichen eines vorhergehenden Crashs? Oder hattest du beim Crash ein anderes, komplexeres OSD offen?


    Gruss
    Thomas

  • Quote

    Gemäss deinem Log geht der GPU der Speicher aus. Das ist grundsätzlich denkbar, da der Speicherbedarf der GPU mit den letzten Firmware-Updates ein klein wenig gestiegen ist.


    Ich nutze für die GPU 512MB Speicher, mehr geht glaube ich nicht. :D


    Quote

    Sollte er zumindest nicht, ausser du hast die Einstellung auf "immer" stehen. Kannst du das Problem auch nach einem Neustart nachvollziehen, oder gibt es evtl. Speicherleichen eines vorhergehenden Crashs? Oder hattest du beim Crash ein anderes, komplexeres OSD offen?


    Ich nutze als Skin den "skinnopacity". Eigentlich macht der bisher keine Probleme.
    Ansonsten schaue ich mir das am Sonntag mal genauer an. Danke erstmal für die schnelle Info. :)


    Gruß, Uwe



    EDIT: mit dem Plugin rpihddevice-1.0.3 habe ich die Crashs nicht. Das Plugin aus dem git teste ich am Sonntag nochmal genauer, eventuell habe ich hier auch was verbockt. ;)

  • Thomas: könntest bitte mal den GCC6 Patch von hier übernehmen?

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.1.6) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Stretch 64Bit | VDR 2.4.5 mit SAT>IP, epgsearch, live, markad
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 3.2+git | Linux Kernel 5.4.72 | VDR 2.4.5 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Extrecmenu, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!