Vorschlag: "Formatierungssprache" für Skins

Hallo Brougs78,

die Idee ansich ist natürlich reizvoll, allerdings werde die meisten User wohl noch immer eine normale FF-Karte nutzen, d.h. mit vielen unterschiedlichen Farben im OSD wird es wohl schwierig.

Was unterschiedliche Farben angeht, habe/hatte ich einen wesentlich einfacheren Gedanken, der sich auch nur auf die in meinen Plugins verwendeten Symbole bezieht. Die Nummern dieser Symbole (zumindestens beim ExtRecMenu-Plugin) bleiben innerhalb eines bestimmten Bereiches, so dass man dies nutzen könnte, um zumindestens die Symbole andersfarbig anzuzeigen. Bei meinem EPG-Plugin würde das z.B. auch die Fortschrittsbalken mit einbeziehen.

Habe mich damit bis jetzt aber nur theoretisch auseinandergesetzt, auch, weil ich erst ein Skin-Plugin zum Testen zusammenschustern müsste. Ich habe auch noch nicht durchgerechnet, ob bei z.B. einem angepassten ST:TNG-Skin das OSD einer FF-Karte noch ausreicht.

Soviel zu meinen Überlegungen. Die Verlinkung ist nicht das Thema, obwohl es ein Dateianhang auch getan hätte

Gruß
Nordlicht

Hi,

um das hier mal nicht total versacken zu lassen: ich bin schon länger mit der Idee schwanger, ein eigenes Skin-Plugin zu schreiben. Und vorgestern abend war die Geburt

Ich hab mir den ST:TNG-Skin von VDR in ein Plugin gepackt und um dann meine Ideen umsetzen zu können. Ich bin noch nicht fertig, aber meine oben genannte Idee, die Symbole aus meinen Plugins andersfarbig darzustellen, konnte ich schon umsetzen. Um nicht mit der Anzahl der Farben ins straucheln zu kommen, nutze ich dafür die gleiche Farbe wie für die nicht selektierbaren Einträge.

Also mir gefällt's

Gruß
Martin

Nur mal am Rande gefragt: Lässt das VDR-Framework es eigentlich zu das Menüsystem komplett zu ersetzen, so dass man nicht ins OSD, sondern wie MMS2 beliebige Grafiken als Menüsystem umsetzen kann?

Echtes OSD benötigt man eigenltich nur beim Umschalten wenn die Kanalinfo unten eingeblendet wird. Ansonsten wird das erheblich eingeschränkte OSD für das VDR-Menüsystem 'missbraucht' weil es noch keine effiziente Möglichkeit gibt Fullscreen-Menüs zu rendern und als StillMpeg-ähnliche Bilder anzuzeigen.

Ich bin mir sicher, dass wenn ein paar Leute die sich mit dem Inneren des VDRs auskennen, der Sache annehmen würden, es irgendwann ein grafisch uneingeschränktes Menüsystem geben würde. Also nie mehr Farbeinschränkungen, unkenntliche Symbole, Font-Aliasing etc.

Gruß
Jarny

VDR bietet eine API an, mit der du komplett selber auf's OSD zeichnen kannst. Das Menü-System und die Skins von VDR baut auf diese API auch nur auf. Das größte Problem in meinen Augen ist der stark beschränkte Speicher der FF-Karten (nur ca. 90kB). Deshalb die Farbeinschränkungen, fehlenden Antialiasing usw. Mich persönlich stört das zwar nicht, ich habe hier das Softdevice-Plugin am laufen, aber wenn man was "für die Masse" schreiben will, muss man das berücksichtigen.

Gruß
Martin

Ich dachte eigentlich, dass man gar nichts mehr ins OSD zeichnet, sondern in eine Art Framebuffer der dann über den Mpeg-Encoder der FF als Bild ausgegeben wird (genauso wie man über das Image-Plugin jedes beliebige Photo ohne Einschränkung anzeigen kann).
Ein OSD im Sinne von Überlagerung/Überblendung einer Anzeige über dem Fernsehbild braucht man bei den Menüsystem des VDRs doch eigentlich gar nicht.

Rein theoretisch sollte man anstatt in den eingeschränkten 90kB-Puffer des OSDs in einen richtigen uneingeschränketen (volle PAL-Auflösung, 24 Bit Farbtiefe) Framebuffer zeichnen können und diesen dann komprimiert über den Mpeg-Decoder der FF ausgeben können.
Rein praktisch wird das wahrscheinlich niemand mehr umbauen können, weil es zu tief im VDR-Framework verwurzelt ist.
Genau darauf hat meine Frage gezielt, ob das Framework es zulassen würde die OSD-Klassen für das Menüsystem einfach auszutauschen gegen entsprechend leistungsfähigere Klassen die in einen eigenen Framebuffer zeichnen und diesen dann wie ein StillImgae an die FF schicken um ihn am Fernseher auszugeben?

Gruß
Jarny

Um damit z.B. ein Menü-System mit dynamischen Inhalten zu erstellen, wäre einiges an Rechenleistung nötig, zumindestens wenn man von der Ausgabe über eine FF-Karte ausgeht. Immerhin muss das Fernsehbild erst dekodiert werden, das OSD oder was auch immer drübergezeichnet und das ganze dann wieder nach MPEG zurückencodiert werden und das für jedes einzelne Bild. Ich denke, das ist in keinster Weise praktikabel. Wenn man sich allerdings auf Ausgabe-Devices mit Full-RGB-OSD beschränkt, wie z.B. eine gemoddete FF-Karte oder das Softdevice-Plugin, kann man auch die momentan angebotenen Klassen und Funktionen von VDR nutzen.

Man muss sich aber auch vor Augen halten, was man will. Letztendlich ist VDR eine Software zum Fernsehen und zur Aufzeichnung von Sendungen. Ich kann zwar nicht für Klaus sprechen, aber ich denke, dass er die Funktionalität von VDR auf diesen Zweck hin ausgerichtet hat.

Gruß
Martin

Zitat

Originally posted by nordlicht
Man muss sich aber auch vor Augen halten, was man will. Letztendlich ist VDR eine Software zum Fernsehen und zur Aufzeichnung von Sendungen. Ich kann zwar nicht für Klaus sprechen, aber ich denke, dass er die Funktionalität von VDR auf diesen Zweck hin ausgerichtet hat.

In diesem Sinne kannst du jederzeit für mich sprechen

Freilich sind bunte, hochauflösende und womöglich in 3D animierte Menüs schön anzuschauen, aber für die eigentliche Funktionalität bringen sie nichts. Ob ich jetzt einen Kanal oder eine Aufzeichnung über ein super-wuper-3D-24-bit-graphisches-menü oder über ein simples OSD auswähle, letztendlich will ich den Film sehen - das Menü ist nur Mittel zum Zweck und typischerweise nur wenige Sekunden da.

Gruß
Klaus

nordlicht
Ich glaube, wir reden aneinander vorbei.
Ich denke, man braucht für das Menüsystem (also zB. das Hauptmenü) NICHT die Funktionalität einer Überlagerung von einem laufenden Film von dem man nichts mitbekommt weil eben das Menü komplett drübergezeichnet ist. Die einzige Stelle wo man sowas wirklich braucht ist beim Zappen wenn der Kanalwechsel dargestellt wird. Dafür ist das OSD gedacht.
Für die Menüs des VDRs benutzt man gezwungenermaßen das OSD weil es noch nichts anderes gibt. Zum Darstellen von Fullscreen-Menüs muss man aber eigentlich nicht wie du oben schreibst das laufende Fernsehbild encodieren um es danach sofort wieder mit dem eigentlichen Menü zu überzeichnen. Diesen Schritt kann man komplett weglassen. Der einzige Mehraufwand ist der Kodierungsschritt vom Framebuffer nach (Still)Mpeg. Ausserdem sind bei Menüs keine 25 Bilder pro Sekunde nötig, 10 Fps reichen völlig aus, mehr hat und braucht man bei dem jetzigen OSD-Menü gefühlsmäßig auch nicht. Das könnte aber auch mit der Tastenwiederholung zusammenhängen.
Vielleicht sind die Mpeg-Menüs sogar insgesamt schneller, wenn man mit dazurechnet, dass das OSD über einen sehr langsamen Bus angekoppelt ist und der Mpeg-Encoder über einen viel schnelleren Zugriff verfügt. Wer weiss!?

kls
Klar braucht man keine super-wuper-3D-24-bit-Grafik-Menüs, von denen redet ja auch keiner hier. Dem Threadstarter ging es zB. nur um eine kleine Erweiterung bei irgendwelchen Symbolen oder eine neue Farbe um ein Menü übersichtlicher zu gestalten. Bei einigen anderen Plugins wünscht man sich auch händeringend mehr Speicher um irgendwelche Elemente vernünftig zu gruppieren oder mal ein kleines Bildchen zu zeigen (zB: Mp3ng, TV-On-Screen). Bei dem Aufnahme-Menü im VDR fände ich es zB. schön, wenn man im oberen 2/3 in der Aufnahmeliste scrollen kann und im unteren Drittel schon gleich die Beschreibung der Aufnahme zu sehen ist (genial bei Serien wo alle Aufnahmen gleich lauten). Das sollte grafisch wahrscheinlich auch noch mit dem Standard-OSD möglich sein.
Wenn man sich mal die ganzen Oberflächen von anderen existierenden MediaCenter anschaut, dann haben die wenigsten eine verhunzte GUI obwohl sie einen uneingeschränkten Framebuffer für die Menüs zur Verfügung haben. Die Oberflächendesigner können damit schon umgehen ohne einen visuellen Overkill zu erzeugen.

BTW: Mich hat eigenltich nur mal interessiert, ob es sich theoretisch halbwegs einfach in den VDR integrieren ließe ohne das ganze Menükonzept über den Haufen schmeissen zu müssen.
Wirklich einschränken tut das OSD eigentlich nur beim mp3ng, das hab ich nicht nur ein paar Sekunden auf dem Bildschirm, sondern oftmals mehrere Stunden Zugegeben, das ist ein Ausnahme-Plugin.
Gruß
Jarny

PS: Gabs nicht vor Jahren mal ein SNES-EMU der das Videobild einer SNES auf die oben beschriebene Weise darstellen konnte? Ich meine sowas in Erinnerung zu haben?

Es muss ja net immer gleich ne Mediacenter-GUI sein.
Nen "ansprechendes" OSD wuerde VDR imho gut
zu Gesicht stehen.
Problem ist aber imho nicht der Speicher (der laesst sich aufruesten),
sondern die Geschwindigkeit.
Bei nem 256-Fullscreen OSD sehnt man sich sehr schnell nach
ner ungemoddeten Karte zurueck.
Spaetestens wenn man beginnt zu scrollen.
Ich hatte mal versucht sowas nachzubilden.
Um 8.00h morgens hatte ich dann entgeistert aufgegeben.
Das Palettenhandling ist auch Murks.
Jedenfalls hatte ich es nicht geschafft bei mehreren 8-bit Subareas
zu verhindern , dass die letzte Subarea immer die Paletteneintraege der
Vorherigen ueberschreibt.

(Morone mit 2. Account , da Passwort vergessen :tdw)