Beiträge von kanadakruemel

Ich habe den Pull request entfernt. Wie schon erwähnt , kann man dasselbe mit nginx/apache erreichen. Wäre dann eine Sache weniger, die im Plugin zu warten ist.

Viele Grüße,

Micha

Hi Markus,

Punkt 2 und 3 werde ich noch anpassen.

Die PO Dateien hatte ich eigentlich gar nicht weiter (wissentlich) angefasst. Ich schau mal, wo die Änderungen herkommen und erzeuge nochmal einen sauberen CR. Wird aber leider wohl erst zum Wochenende.

Gruß,

Micha

Ist schon etwas her, seit ich das implementiert habe. Kann sein, dass es wegen absoluter Pfade war und ich mag HTML rewrite im Reverse Proxy nicht.

Ich nutze auch nginx als Reverse Proxy für alle möglichen Dienste. Da fand ich das mit dem Präfix eine saubere Lösung.

Gruß,

Micha

Ich hab mich da an anderer Software, wie z.B. tvheadend (--http_root) orientiert.

Wenn es kein anderer braucht, dann einfach den pull request rejecten.

Viele Grüße,

Micha

Hi zusammen,

ich habe ins live Repository einen pull request gestellt, mit dem man einen URL Präfix für die gesamte live Seite setzen kann.

Das erleichtert z.B. den Betrieb hinter einem Reverse Proxy. Man könnte auch mehrere VDR durch unterschiedliche Präfixe in einem Proxy bündeln.

Die Einstellung des Präfix erfolgt über das Setup Menü des Plugins.

Vielleicht hilft es ja dem ein oder anderen.

Viele Grüße,

Micha

Hi zusammen,

mit angehängtem Patch sollten die nervigen Streifen in der 0.9.7 des osdteletext plugins verschwunden sein.

@rofaror

The attached patch should remove the annoying blank lines in graphics characters in the osdteletext plugin. Maybe you could include it into your repository.

Gruß/Regards,

kanadakruemel

Hi zusammen,

aufgrund der Diskussion hier habe ich die 0.9.7 auch mal ausprobiert und sehe auch die Streifen, egal ob mit oder ohne teletext2 font.

Das Problem hatte ich im Laufe der Entwicklung des Patches für VDR 2.3.1 damals auch. Am WE versuche ich mal die Ursache zu finden und ggf eine Lösung.

Gruß,

kanadakruemel

Hi,

ich nutze Radiodroid. Gibts im F-Droid oder Google Play Store. Steht unter GPL3 und tut genau das, was es soll - Internetradio abspielen. Man kann auch aufnehmen, es als Wecker benutzen - brauche ich aber nicht. Die Liste der Radiokanäle kommen von radio-browser.info. Direkt im Programm kann man aber keine URLs angeben.

Dafür habe ich immer Webradio aus dem F-Droid Store genommen. Mittlerweile brauche ich das aber nicht mehr, da bei radio-browser.info alle für mich relevanten Stationen dabei sind.

Gruß,

kanadakruemel

Hallo,
hier ist die aktuelle Version meines OSDTeletxt TTF Patches. Die störenden Linien zwischen den Zeichen sollten jetzt beseitigt sein. Als Standardfont habe ich jetzt FreeMono:Standard eingetragen. Bei diesem Font werden u.a. die Zeichen unten nicht abgeschnitten (bei z.B. g q f usw.). Auch wird jetzt bei jedem Zeichen der Hintergrund vorinitialisiert. Ob das reicht, die überlappenden Seiten beim openglosd SHD zu verhindern, weiss ich leider nicht.

Gruß,
kanadakruemel

louis
Ok, schade, dass es mit va-api nicht geht. (hat SHD nicht einen nur-opengl-modus? könnte man den vielleicht mit openglosd aufbohren?)
Ich verwende eine cBitmap zum Zeichnen und nein, ich habe sie nicht mit Fill initialisiert (muss es . Das könnte ich aber heute Abend schnell mal einbauen. Muss es clrTransparent sein, oder könnte ich auch mit einer beliebigen Farbe füllen? Ich bin davon ausgegangen, dass DrawText den Hintergrund mit der Farbe füllt, die ich bei DrawText angegeben habe.

MegaV0lt
Es ist schwierig, einen Font vorzugeben, da ich nicht weiß, ob er installiert ist. Ich muss mal schauen was passiert, wenn der angegebene Font nicht gefunden wird. Was meinst Du mit "wie es das Plugin ursprünglich gemacht hat"? Dann brauchst Du doch den Patch nicht. Maximal den von reufer am Threadanfang. Ziel des Patches soll natürlich eine fehlerfreie Darstellung sein, aber mit "schönem" Text.

crow
Dann schau ich nochmal, ob beim Holen/Verwenden der Settings noch was im Argen liegt. Ich hab mal meine Teletext Breite/Höhe wie bei Dir eingestellt, da kamen dann auch die Streifen zwischen den einzelnen Zeichen. Mit meinen Einstellungen (B/H: 1280/1056) sind die weg. Das könnte vielleicht auch mit dem Problem der nicht initial gefüllten Bitmap zusammenhängen, das Louis erwähnt hat. Das sehe ich dann heute Abend...
Anbei ein Screenshot vom teletext auf ServusHD mit meinen Einstellung (und plain SHD).

Gruß,
kanadakruemel

maz
Dass bei Dir das Speichern der Settings nicht geht, ist schon sehr eigenartig. Hat der VDR-User die Rechte zum Schreiben in die settings.conf bzw. kannst Du andere Einstellungen speichern? Ich habe an der Stelle eigentlich nur einen Punkt für den Font hinzugefügt.
Bei dem Problem mit den überlagerten Seiten weiß ich gerade auch nicht weiter. Ich nutze die Standard DrawBitmap Funktion des OSD. louis, reufer Wird da vielleicht jedesmal ein neuer Layer im OSD erzeugt? Oder muss man die neu gezeichnete Bitmap irgendwie "mergen"?

crow
In Deinen Settings steht ja der Dejavu Sans Mono Font, laut log wird aber der Courier:Bold verwendet. Gehört das log zu den Einstellungen? Bei mir verwendet er den eingestellten Font (in Deinem Beispiel wär das der Dejavu). Dann müsste ich da nochmal schauen. Courier:Bold ist der Standard Fixed Font des VDR (definiert in fonts.c). Etwas besser ist die Ausgabe bei Dir ja geworden, der "Augenkrebs" ist weg Allerdings verstehe ich die Lücken zwischen den Buchstaben noch nicht ganz. Ich prüfe das nochmal.

louis
Kurze Frage dazu. Ich kann im Moment nur auf meinem Laptop testen. Da nutze ich den Intel-Treiber, der ja nur va-api hat. Kann man da irgendwie das shd openglosd zum Laufen kriegen. Die NVIDIA GPU ist nur per optimus (bumblebee) erreichbar, da bekomme ich kein Bild/OSD, wenn ich das nutzen will. Vielleicht hat ja jemand einen Tipp, wie ich mit dieser Konfiguration ein shd openglosd nutzen kann.

MegaV0lt
Die abgeschnittenen Buchstaben hängen stark vom verwendeten Font ab (wie die glyphs im font definiert sind, ob das bearingY gleich der Höhe des Zeichens ist). Mit den VDR Font Bordmitteln komme ich da vermutlich nicht weiter. Bliebe nur, die freetype Bibliothek direkt zu nutzen und dort alle Font Metriken auszulesen. Dann kann ich aber die (beschleunigte) DrawText Funktion nicht mehr nutzen. Die liegt zwar im Moment aufgrund der Font Width Problematik der HiLevel OSD Treiber auf Eis, könnte dann aber gar nicht mehr verwendet werden. Als Workaround empfehle ich, ein wenig in der Fontliste zu suchen, welcher Font dieses Problem nicht hat. Ich nutze den FreeMono:Standard. Ich schaue aber nochmal, ob da noch ein Bug drin ist, der die Teile der Buchstaben überschreibt.

Gruß,
kanadakruemel

Hallo,

anbei eine neue Version des osdteletext-ttf patches. Der teletext.ttf Font wird nun nicht mehr benötigt, die Grafikzeichen werden ähnlich der "alten" Methode erzeugt. Für den Text wird der im Setup des Plugins eingestellte Font benutzt. Standard ist nun der Default Fix Font (definiert in font.c des VDR). Die Character Konvertierung für alle unterstützten Sprachen sollte funktionieren. Bei mir treten mit dieser Version keine Grafikfehler mehr auf, allerdings kann ich leider nicht mit den Hi-Level OSD devices testen.

crow
Scheinbar wurde bei Dir der teletext2 font nicht gefunden und daher versucht, den Standardfont immer größer zu skalieren. Das sollte mit dieser Version behoben sein. Falls nicht, bitte im Setup des Plugins nochmal neu einen Font wählen.

@rofaror
This version of the osdteletext ttf patch doesn't need the teletext.ttf font anymore. Graphics chars will be rendered using the old method of the plugin.
Character conversion should work again for all supported language sets. Internally the characters are stored as unicode positions (e.g. 0x00C4 for a german Ä) and converted into UTF8 with the Utf8CharSet function from tools.h.

Best regards,
kanadakruemel

@rofaror
You are right, character conversion has yet to be done correctly. First I would like to get rid of the teletext font dependency an habe a look after crows problem. But character conversion is the very next task.

best regards,
kanadakruemel

HI,

M-Reimer, Copperhead
Mea culpa fürs verwechseln. War wohl zu spät gestern Abend.

tomas,
Danke für den Vergleich. Dann sollte es eigentlich auf dem RPI genauso aussehen.

crow
Das sieht ja wirklich übel aus. Die Fonts scheinen viel zu groß zu sein. Welches Ausgabeplugin nutzt Du denn dafür? Ich versuche mal, das bei mir mit den von Dir eingestellten OSD Größen und Fonts nachzustellen. ORF hab ich leider nicht zum Testen.

louis, Thomas
Das habe ich auch schon gesehen, dass man die Breite nicht abfragen kann. Das wäre zumindest eine erste, sinnvolle Ergänzung zur cFont API. Die Initialisierungswerte sollte man auch wieder abfragen können. Auch bei den anderen Vorschlägen habt Ihr meine Zustimmung. Das Ausgabedevice weiß ja am Besten, wie es mit Textdarstellung umgeht. Mal sehen, ob bzw. was Klaus dazu sagt.

Gruß,
kanadakruemel

Dann ist das Aussehen ja erstmal klar.

Ich habe mal ein paar Logmeldungen bzgl. Fontgrößen etc. eingebaut. Außerdem habe ich die Ausgabe geändert, indem ich erst den Text in eine Bitmap schreibe und diese dann per DrawBitmap ins OSD schreibe. Damit wird zwar die beschleunigte Textausgabe nicht benutzt, es sollte dafür aber überall gleich aussehen. Wenn Du eine Möglichkeit findest, die beschleunigte Ausgabe mit monospaced fonts zu nutzen, kann ich das ja wieder ändern (oder per Makefile Parameter schaltbar machen).

Gruß,
kanadakruemel

Hallo Louis

ich habe mir mal die Implementierung von DrawText in openglosd.cpp von softhddevice-openglosd angeschaut. Demnach wird nur die Fonthöhe benutzt, die ggf. bei cFont::CreateFont angegebene Fontbreite wird nicht genutzt. Genau dieses Feature brauche ich aber, und so sieht auch der Screenshot von Tomas aus. Ich nehme an, das RPI Device nutzt eine ähnliche Implementierung. cFont bietet leider keine Möglichkeit, auf die übergebene Fontbreite zuzugreifen (cFont::Size liefert die Höhe). Im Moment arbeite ich an einem Workaround dafür, der dann aber nicht die beschleunigte Textausgabe nutzt.

Gruß,
kanadakruemel

Hi Tomas und Louis,

tomas
wenn nichts eingestellt wurde, ist der Textfont == dem Grafikfont, also teletext2:Medium. Es sollte dann eigentlich aussehen wie früher. Fürs Auge sind natürlich alle anderen Fonts besser geeignet. Ich nehme z.B. den FreeMono:Standard für Text. Danke auch für den Screenshot, das zeigt sehr gut den Unterschied.

louis
Die Fontgrößen werden immer gleich berechnet. Sie sind nur von der im Setup eingestellten Größe des Teletext Fensters abhängig. Die tatsächliche Größe der Glyphs ermittle ich über die eingebauten cFont Funktionen. Für das Zeichnen wird die Funktion DrawText der cOsd Klasse verwendet. Ich hab da jetzt nicht nachgeschaut, aber ist die für beschleunigte Ausgabedevices anders implementiert?
Andererseit sieht man im Screenshot von Tomas schön, dass die Zeichen zu schmal sind. Ich bau mal ein paar Logausgaben mit der Größe der berechneten Fonts etc. ein.

Mir würde dann nur noch einfallen, für Grafikzeichen den bisher verwendeten internen Font von osdteletext zu nehmen und die Zeichen selbst zu "malen", also nicht per DrawText, sondern DrawBitmap. Das würde dann auch die Abhängigkeit vom teletext font lösen.

Gruß,
kanadakruemel

Hallo maz und Thomas,
erstmal danke fürs Testen. Scheinbar wird bei Euch die Fontgröße des Grafikfonts falsch berechnet (oder es wird der falsche Font benutzt, allerdings muss der dann auch teletext2:medium (Fontname) benannt sein).... Da muss ich mal noch ein paar Logausgaben einbauen.
Bei mir sieht es wie im angehängten Screenshot aus.

maz
Benutzt Du das normale softhddevice, oder die opengl Variante? Dann könnte es mit der Beschleunigung zu tun haben, da ja das RPI device da ähnlich funktioniert. Ich nutze derzeit das "normale" softhddevice. Ich schau mail, ob ich die opengl Variante auf meinem Laptop zum Laufen kriege.

Gruß,
kanadakruemel

Ich habe mal den Vorschlag von Copperhead aufgegriffen und das osdteletext plugin so umgeschrieben, dass die OSD Funktion DrawText zur Darstellung benutzt wird. Für die Videotext Grafiksymbole wird der teletext.ttf Font des Kodi Projekts im Font Suchpfad benötigt (z.B. unter /usr/share/fonts). Für normale Texte kann ein beliebiger monospaced Font im Plugin Setup eingestellt werden. Die Text-Darstellung sieht dadurch natürlich viel besser aus.

Der Patch ist noch nicht komplett, funktioniert hier aber schon gut (der WAF Faktor ist durch die bessere Textdarstellung extrem gestiegen!).
Anzuwenden ist der Patch gegen den letzten git Stand.

Es gibt noch folgende Einschränkungen:

• Bisher sind nur deutsche Sonderzeichen angepasst
• Es werden nur noch TrueColor OSD unterstützt (z.B. keine SD-FF mehr)
• Bei den Grafikzeichen gibt es noch leichte Grafikfehler (teilweise einzelne Linien zwischen den Grafikzeichen)
• Die Ermittlung der Fontgröße ist ein ziemlicher Hack (ich muss die Fontgröße so setzen, dass die Größe der Glyphs meinen Vorgaben entspricht, also ohne "Rand" um die Glyphs), falls jemand eine Idee hat...
• Ich konnte nur auf meinem System (benutzt SHD) testen, wie es sich z.B. auf dem RPI verhält wäre sehr interessant

Vorteile des Patches:

• nutzt direkt das OSD ohne zusätzliche Bitmap/Pixmap, dadurch entfällt das Umkopieren der Bitmap bei Änderungen des Seiteninhalts
• unter vdr 2.2.0 und vdr 2.3.1 lauffähig
• viel bessere Textdarstellung

Gruß,
kanadakruemel

Hi Thomas,
danke für die Rückmeldung. Werde ich noch mit vorsehen. Allerdings arbeite ich gerade an einer Version, die den Vorschlag von Copperhead umsetzt. Da fällt dann das ganze rumkopieren etc. weg und die Schrift sieht auch besser aus. Dauert allerdings noch ein wenig (insb. Grafikzeichen und solche Dinge wie doppelte Höhe usw.).

Hast Du jetzt Unterstützung von Anitaliasing im rpidevice implementiert?

Gruss
kanadakruemel