TrueColorOsd Fehlersuche

  • Ich probiere zur Zeit mal wieder skinreelng ans laufen zu bringen.
    In dem großen Thread wurde das ganze ja auch schonmal angesprochen, dort hatten ein paar andere genau das gleiche Problem wie ich, nachdem das TrueColor aus dem reelvdr in unseren VDR reingepatched ist, erscheint beim auswählen von skinreelng gar kein OSD mehr.


    Einen kleinen Erfolg habe ich da auch mittlerweile zu verzeichnen. Ich bekomme jetzt zumindest schonmal etwas angezeigt, die Bitmaps fehlen aber noch.


    Problem liegt irgendwo bei der Farbtiefe, mit 32bpp funktioniert es nicht, mit 24bpp schon.


    In der reel.c im skinreelng Verzeichnis werden ja an mehreren Stellen die Areas festgelegt. Dort sind dann Zeilen wie diese zu finden:


    Code
    1. tArea Areas[] = { {0, 0, xBottomRight - 1, yBottomBottom - 1, 32} };


    Der letzte Parameter gibt dabei bpp an. Ändert man jetzt überall die 32 auf eine 24 ab, erscheint auch mit skinreelng ein OSD.


    Was mich jetzt nur wundert, warum funktionieren 24bpp?
    Macht der normale VDR nicht normalerweise nur 8bpp mit Speichermod?
    Oder ist dsa im normalen VDR schon irgendwo auf 24bpp gesetzt?
    Wenn ja wo? Ich konnte es bis jetzt nicht finden.


    Muss doch irgendwie zu schaffen sein das wir bei unserem VDR auch ein TrueColor OSD hinbekommen ;)

  • Irgendwie wird das ganze immer eigenartiger.


    Die png werden in der reel.c mit der Funktion cOsd::DrawImage aufgerufen. Hier ein paar Beispiel Zeilen.


    Code
    1. osd->DrawImage(imgChannelInfoHeaderLeft, xTitleLeft, yTitleTop, false);
    2. osd->DrawImage(imgChannelInfoHeaderCenterX, xTitleLeft + Roundness, yTitleTop, false, xTitleRight-xTitleLeft - 2 * Roundness,1);
    3. osd->DrawImage(imgChannelInfoHeaderRight, xTitleRight - Roundness , yTitleTop, false);


    Gucken wir uns jetzt diese Funktion in der osd.c des reelvdr an, finden wir dort folgendes:


    Code
    1. void cOsd::DrawImage(u_int imageId, int x, int y, bool blend, int horRepeat, int vertRepeat) // GT: True color support.
    2. {
    3. // No implementation.
    4. }
    5. void cOsd::SetImagePath(u_int imageId, char const *path) // GT: True color support.
    6. {
    7. // No implementation.
    8. }


    Meiner Ansicht nach dürfte also mit diesem Code nirgends ein Bild kommen, auch nicht auf der Reelbox.


    @RMM: Fehlt das noch im public SVN oder interpretiere ich euren Code falsch?

  • Zum testen hab ich jetzt mal 2 Diffs erstellt.


    truecolor.diff ist für VDR 1.6.0 welcher mit dvb-s2 und h264l gepatched ist. Der Patch fügt die TrueColorOsd Funktionen aus dem reelvdr hinzu.
    Hinweis: Das OSD-Speedup vom rnissl Patch wird durch das Diff wieder entfernt.


    skinreelng.diff ändert die bpp bei der Area Festlegung auf 24 und enthält außerdem ein paar (mitunter Quick&Dirty) Anpassungen, damit das mit einem normalen VDR kompiliert.


    Damit funktioniert jetzt zumindest schonmal eine teilweise Anzeige des skinreelng. Halt nur in 24bpp und die ganzen png werden nicht angezeigt.

  • Quote

    Original von Maniac
    Irgendwie wird das ganze immer eigenartiger.


    Die png werden in der reel.c mit der Funktion cOsd::DrawImage aufgerufen.


    Ok, ich hab den Code falsch interpretiert es wird die Funktion cOSDImageBitmap::DrawImage() genutzt welche sich in bitmap.c befindet.


    Edit: Ist doch quatsch. cOSDImageBitmap::DrawImage() wird nur in der logo.c benutzt.

  • Das Thema interessiert mich auch brennend.
    Wäre auch sinnig alles über das OSD nun hier zu bündeln.


    Nach Deinen Anregungen werde ich mich am Wochenende auch nochmal hinsetzen und mein Glück probieren.


    cu
    Andreas

  • Schorsch hat im Reel Forum geantwortet ob das absichtlich nicht in der osd.c ist.


    Die Anpassungen in der osd.c sind veraltet und werden nicht mehr genutzt, die aktuelle Implementierung des TrueColor OSD befindet sich im reelbox Plugin.


    Damit es mitkompiliert wird beim "make plugins" ein SKINREEL=1 mitgeben, allerdings mag das so bei mir noch nicht durch den Compiler. Mal sehen was man da machen kann.

  • Dank der Hinweise von Schorsch habe ich jetzt das skinreelng mit png am laufen. Das dumme dabei ist nur das jetzt wo es in 32 Bit läuft und auch schön die Bilder anzeigt fehlt die Schrift :)


    Ich vermute mal das liegt irgendwo im geänderten Fonthandling oder so. Wenn ich das auch noch hinbekommen hab, gibts nochmal einen aktuellen Satz an diffs.

  • Beim kompilieren mit reelskin=1 kommt folgendes:


    fs453settings.c: In member function »void cFs453Settings::LoadSettings()«:
    fs453settings.c:88: Fehler: ungültige Umwandlung von »const char*« in »int«
    fs453settings.c:88: Fehler: Argument 1 von »tColor cTheme::Color(int)« wird initialisiert
    fs453settings.c:89: Fehler: ungültige Umwandlung von »const char*« in »int«
    fs453settings.c:89: Fehler: Argument 1 von »tColor cTheme::Color(int)« wird initialisiert
    fs453settings.c:90: Fehler: ungültige Umwandlung von »const char*« in »int«
    fs453settings.c:90: Fehler: Argument 1 von »tColor cTheme::Color(int)« wird initialisiert
    fs453settings.c: In constructor »cSkinDisplayProgbar::cSkinDisplayProgbar(cOsd*, int, int, const char*)«:
    fs453settings.c:214: Fehler: ungültige Umwandlung von »const char*« in »int«
    fs453settings.c:214: Fehler: Argument 1 von »tColor cTheme::Color(int)« wird initialisiert
    fs453settings.c:215: Fehler: ungültige Umwandlung von »const char*« in »int«
    fs453settings.c:215: Fehler: Argument 1 von »tColor cTheme::Color(int)« wird initialisiert
    fs453settings.c:216: Fehler: ungültige Umwandlung von »const char*« in »int«
    fs453settings.c:216: Fehler: Argument 1 von »tColor cTheme::Color(int)« wird initialisiert
    fs453settings.c:217: Fehler: ungültige Umwandlung von »const char*« in »int«
    fs453settings.c:217: Fehler: Argument 1 von »tColor cTheme::Color(int)« wird initialisiert
    make[1]: *** [fs453settings.o] Fehler 1


    Was hast Du denn dagegen gemacht ?


    Gruss


    Stefan

    Server HW:
    Asrock Q1900M + 4GB + 2x CineS2 5.4, SSD, 2TB Toshiba 2.5" (USB), 3TB Seagate (USB); 2TB Samsung; 1.5 Seagate (USB), picoPSU + DC/DC 200W
    SW:
    Debian (arranged), OpenMediaVault kralizec; VDR-2.1.6 + dynamite, live etc; Mysql running DB for EPG2VDR, XBMC


    Clients:
    1) TBS2910 freescale imx6 + OpenELEC
    2) RPI, 1GHZ, VDR-2.1.6
    3) RPI, 1GHZ, VDR-2.1.6
    4) cubietruck

  • Anfangs erst das auskommentiert was ihn gestört hat und mich nicht interessiert, wie das mit dem fs453 oder in der bsptruecolorosd.


    Als das zuviel geworden ist hab ich dann einfach die "#if SKINREEL" aus HdOsd, HdOsdProvider und HdTrueColorOsd entfernt, und dann doch wieder ohne SKINREEL=1 gebaut ;)


    Danach dann noch bei CreateTrueColorOsd() das OSD Level dazu gebastelt, schon hat er die Funktion aus HdOsdProvider.c benutzt. Dann vorerst den Inhalt von CacheFont() auskommentiert, da das alles mit VDR 1.6 nicht mehr passt, wegen dem Truetype Fonthandling direkt im VDR.


    Jetzt verzweifel ich gerade daran irgendwie die Schrift darzustellen.

  • Oops, das überschreitet meine Fähigkeiten wohl...

    Server HW:
    Asrock Q1900M + 4GB + 2x CineS2 5.4, SSD, 2TB Toshiba 2.5" (USB), 3TB Seagate (USB); 2TB Samsung; 1.5 Seagate (USB), picoPSU + DC/DC 200W
    SW:
    Debian (arranged), OpenMediaVault kralizec; VDR-2.1.6 + dynamite, live etc; Mysql running DB for EPG2VDR, XBMC


    Clients:
    1) TBS2910 freescale imx6 + OpenELEC
    2) RPI, 1GHZ, VDR-2.1.6
    3) RPI, 1GHZ, VDR-2.1.6
    4) cubietruck

  • Ich komme bei der Font Geschichte zur Zeit kaum vorran.


    Ich interpretiere das ganze zur Zeit so:


    Die TrueColor Klassen enthalten eine Funktion cacheFont(), dort wird jedes Zeichen der Schrift als cFont::tCharData abgelegt.
    Wleches über die Funktion

    Code
    1. const tCharData *CharData(unsigned char c) const { return data[code=c]; }


    generiert wird.
    Diese Funktion liefert doch nur den struct tCharData zurück, oder?
    Die Schriftart wird über ein Index angesprochen welcher von der cacheFont() Funktion generiert wird.
    Soll jetzt ein Text dargestellt werden kommt die DrawText() Funktion aus dem TrueColorOsd zum Zug. Dieser wird unter anderem die ID der Schriftart übergeben welche ja vorher über cacheFont() auf der HDe abgelegt wurde.


    Das Problem ist jetzt nur, das es seit Truetype in VDR Einzug gehalten hat, einige Funktionen und Variablen fehlen, worüber die Funktion cacheFont() die einzelnen Zeichen an die HDe sendet.


    Also müssen wir uns jetzt irgendwie aus den neuen Font Klassen den Inhalt für das struct tCharData erzeugen, da wir selbst ja an der HDe nicht schrauben können.


    tCharData sieht wie folgt aus:


    Code
    1. typedef uint32_t tPixelData;
    2. struct tCharData {
    3. tPixelData width, height;
    4. tPixelData lines[1];
    5. };


    width und heigth sollte ja selbsterklärend sein.
    Was steht in lines?


    Wie bekommen wir jetzt tCharData zusammengebaut, damit wir das Zeichen auf der HDe cachen können?

  • Ok, in lines müssen die einzelnen "Zeilen" des Zeichens(zb Buchstabe) als Hexwert, so wie sie auch bei VDR 1.4 kodiert waren. Ich hab das zur Zeit gerade einfach mal per Hand auf nen paar Striche gesetzt, bringt zwar auch nix, man sieht aber schonmal nen Fortschritt ;)


    Hat jemand eine Idee wie ich dort jetzt die richtigen Font Daten unterbringen kann?

  • hab leider keine vorschläge, bin aber brennender mitleser dieses topics ;) nicht dass das hier son monolog wird.

    kuifje
    asus m2n-vm | Athlon 5600 | Nvidia 9300GE | TT S2-3200
    yaVDR 0.4 | 1.7.21
    haddock
    asus p4pe | 2ghz | 3x DVB-S Budget | 2x500gb
    debian lenny 2.6.29.3 | e-tobi 1.7.0 | streamdev cvs | live


    <30.12.07 <igel>sid fuer den gewissen kick>
    <01.04.08 <igel>ich kann eh nix ausser debian pakete installiern>
    <15.12.09 igel hasst linux>
    <23.02.10 <igel> easyvdr is nur easy wenn es easy is>

  • Hmm, die Klasse cGlyph scheint da passende Funktionen für bereitzustellen. Aber aus welchem Grund ist der Prototyp in der font.c zu finden? Der müsste doch eigentlich in der font.h zu finden sein, damit dieser auch per #include genutzt werden kann.

  • Quote

    Originally posted by Maniac
    Hmm, die Klasse cGlyph scheint da passende Funktionen für bereitzustellen. Aber aus welchem Grund ist der Prototyp in der font.c zu finden? Der müsste doch eigentlich in der font.h zu finden sein, damit dieser auch per #include genutzt werden kann.


    Die Details der Font-Implementierung sollen in font.c gekapselt sein.


    Klaus

  • Quote

    Originally posted by Maniac
    kls : Gibt es den eine einfache Möglichkeit mit einem Plugin an die einzelnen Zeichen der Schriftart als uint32 array zu kommen, wie es vor der Truetype Einführung die Funktion cFont::CharData() gemacht hat?


    Das Plugin müsste dann ja alles, was cFreetypeFont::DrawText() macht, nochmal implementieren. Das wäre sicher nicht gut.


    Ein "True-Color" OSD benötigt auf jeden Fall die entsprechende Unterstützung für 32-bit cBitmaps etc. Das muß alles im osd.c erst noch realisiert werden. Es muß ja schließlich auch mit 1-, 2-, 4- und 8-bpp cBitmaps zurecht kommen.


    Klaus

  • Das ganze ist für die Reel HD Extension, die 32 Bit Unterstützung ist im dazugehörigen reelbox Plugin bereits soweit implementiert. Allerdings basiert das ganze bei Reel noch auf VDR 1.4. Eine DrawText() Implementierung gibt es auch schon.


    Das Problem vor dem ich jetzt aber stehe ist, das die Fonts auf der HDe in einen Cache geschrieben werden und die DrawText() Funktion ruft die zu verwendenden Schriftart über eine ID auf, welche vorher von der Cache Funktion generiert wurde.


    Die einzelnen Zeichen der Schriftart werden dabei als struct cFont::tCharData übertragen. Welches von der Funktion cFont::CharData() gefüllt wird.


    Da es in den neueren VDR diese Funktionen und Variablen so nicht mehr gibt, suche ich zur Zeit nach einer Möglichkeit der HDe trotzdem die Daten in der erwarten Form zur Verfügung zu stellen.

  • Ralph.D : Dazu müsste einmal dein Ausgabe Device in der Lage sein ein 32bpp OSD auszugeben und du müsstest das implementieren was Klaus oben geschrieben hat.


    Quote

    Original von kls
    Ein "True-Color" OSD benötigt auf jeden Fall die entsprechende Unterstützung für 32-bit cBitmaps etc. Das muß alles im osd.c erst noch realisiert werden. Es muß ja schließlich auch mit 1-, 2-, 4- und 8-bpp cBitmaps zurecht kommen.


    Klaus


    @All: Ich hab jetzt einfach mal einen Small Font aus VDR 1.4 eingebunden, damit ich nicht nur blind im OSD navigieren muss. Soweit ich das bis jetzt sehen konnte besteht wirklich nur noch das Problem mit dem Text. Alles andere wird wunderbar dargestellt. Es fehlt also nur noch der letzte Schritt der Font Darstellung.


    Dort bin ich aber zur Zeit recht ratlos.


    Kann mich an dieser Stelle jemand unterstützen?
    Es fehlt nur noch das die einzelnen Zeichen der Schriftart jeweils als "struct tCharData" vom Plugin ausgelesen werden können. Dieses struct gibt es aber leider nur bei VDR 1.4, bei 1.6 bekomme ich es nicht wieder implementiert.