[ANNOUNCE] Lader für Textbasierte Skins (text2skin-0.0.8)

Zitat

Original von micmac
Hi,

ich habe VDR 1.3.12, text2skin-0.0.8 und das HighTech16 Skin (das für nicht-gemodette Karten). Wenn ich dann das mplayer-plugin starte, habe ich, wenn ich das OSD-Menü aufrufe, nur den Rahmen des Menüs. Das Menü selber fehlt. mplayer Plugin ist in der Version 0.9.3 installiert. Hat jemand anderes das gleich Problem? Gibts einen Fix?

MfG
mic

Edit: Im syslog oder unter der runvdr gibts keine Fehlermeldungen. Steht immer Aug 17 19:15:37 vdr vdr[14620]: Text2Skin: Menu display update thread started (pid=14620, tid=147462)
Aug 17 19:15:38 vdr vdr[14620]: Text2Skin: Menu display update thread ended (pid=14620, tid=147462)
aber das ist ja ok.

Alles anzeigen

Hi micmac,

ich verwende den Skin auch und hatte auch das Problem.
Habe gerade mal den "mplayer-1.0pre2-slavemode.diff"-Patch der im MP3/Mplayer-Plugin-Patch Verzeichnis liegt, auf den aktuellen Mplayer1.0pre5 angewendet und neu kompiliert.

Bisher scheint das Problem nicht mehr aufzutauchen....

EDIT: Das Problem tritt leider immer noch auf! Und das, wie du schon sagtest, nur bei Avi´s!

Uwe

PS: Habe aber auch gleichzeitig noch den "mplayer-0.9.3-audiostreamid_patch.diff" entfernt, womit der auch vielleicht der verursacher sein könnte!

Hi Uwe,

an dem audiostreamid wirds nicht liegen. Hab hier einen ungepatchten 1.3.12. Plöd wenn man nicht proggen kann wie ich .) Dann kommt man sich ein bischen verloren vor.

Also Angebot steht: Wer sich das mal selber anschauen will bekommt einen test.avi.

MfG
mic

Hi @all,
text2skin 0.0.8 ist ein klasse Plugin um einfach neue Skins zu erstellen,
zur Zeit probiere ich etwas damit herum.

Als Fan des klassischen kantigen Elchi-Looks von dem vdr-1.2.6 mit Elchi-patch
vermisse ich eine Funktion von text2skin beim Umschalten auf andere Kanalgruppen:

Beim alten Elchi-Patch wurde, wenn man mit links/rechts auf die nächste
Gruppe schaltete, der Gruppenname mit Uhrzeit ganz unten am Bildschirmrand
eingeblendet zusammen mit dem oberen Teil der "geschwungenen" Hintergrundgrafik.

Erst wenn man dann mit ok/return bestätigt und auf den ersten Kanal
der Gruppe wirklich umschaltet wurde die "geschwungene" Hintergrundgrafik
nach oben versetzt und darunter die EPG-Anzeige der laufenden und der nächsten
Sendung dargestellt.

Ich würde gerne dieses "aufspringen" bzw. nach oben versetzen der Grafik und
Textelemente auch so haben wenn man einen Gruppenwechsel macht und auf den ersten
Kanal der Gruppe schaltet.

Hat den grossen Vorteil, dass man bei Umschalten möglichst viel vom Bild sieht und
keine Skinelemente "mitten" im Bild hat - das stört mich bei vielen anderen Skins.

Läßt sich sowas in eine nächste Version von text2skin einbauen ?
Ist überhaupt eine neue text2skin Version mit neuen Features (0.0.9 ???) geplant ?

Gruss,
Gromit.......

Bei dem Thema Gruppen hätte ich eine kurze Frage, die eventuell dann auch was mit einem neuen Versionswunsch zu tun hat.

Verwende den lightblue256 Skin und da wird zu jedem Sender ein Icon angezeigt. Beim Zappen durch die Gruppen sieht der Teil des Bereiches identisch aus, allerdings haben die Gruppen kein Icon. Logisch, woher soll der Skinmaker meine Gruppennamen kennen. Kann ich da ähnlich den Kanalicons einfach Dateien anlegen oder muß ich sowas auf die Wishlist setzen?

einfach wie die chanlogos eigenen bilddateien machen, das sollte gehen.

lordjaxom will das aber in 0.0.9 eh "verbessern", ala "if log dann anzeigen ansonsten nix"

-- randy

Hi,
debuglevel des vdr hochsetzen, dann sieh Du in
/var/log/messagen etwas wie
"cant find \"Dritte Programme.mng\"".
Und schon weisst Du wie Deine Icons heissen sollten.
Dies kann Dir keiner vorbereiten, da Du selbst die Namen der Separatoren Dir ausdenkst.

Viel Erfolg!
Harvey

LordJaxom

Zitat

Zu dem angesprochenen Problem: Das ist eine Sache,
die eigentlich genauso funktioniert wie beim alten
VDR auch. Wenn eine Gruppe angezeigt wird, kann
der VDR eine "kleine Kanalansicht" anfordern, die
keine EPG Info enthält. Leider tut VDR das aus
irgendeinem Grund nicht (kann ich also garnichts
dran machen...).

Alles anzeigen

Zitat

%SECTIONS = (
"ChannelSmall" => [
"The channel display. It displays the current programme and number only, ".
"together with some decoration. [UNUSED]",

"Die Kanalanzeige, die nur den aktuellen Kanalnamen und die -nummer mit ".
"etwas Dekoration anzeigt. [UNGENUTZT]"
],

Alles anzeigen

Habe es nach einigem Suchen in items.doc gefunden.
Bedeutet das mit anderen Worten, text2skin 0.0.8 unterstützt alle Definitionen
in einer [ChannelSmall] Section und ich müßte mich damit an Klaus richten ?

Gruss,
Gromit

LordJaxom - Danke für die Hinweise

@all
Ich bin gerade dabei eine neue Skin zu erstellen und
experimentiere z.Zt. etwas mit verschiedenen Bildern herum.
Da beim Umschalten und Menüaufrufen aber doch eine
Verzögerung zu bemerken ist, möchte ich versuchen die
Geschwindigkeit etwas zu erhöhen.

Als nächste werde ich wohl mal die Imlib2 aufspielen da dies ja
lt. readme etwas bringen soll.

Gibt es weitere Erfahrungswerte was schneller angezeigt werden kann:

- Bilder mit 256-Farb Palette oder mit 24-Bit Farbtiefe (16,8 Mio Farben) ?
- möglichst kleine Bilddateien (png/jpg hoch komprimiert) oder gar nicht
komprimiert ?
- Ist ein bestimmtes Bildformat zu bevorzugen ?
- Ein Bild für einen einfarbigen Hintergrund nehmen oder
besser mit rectangle ein Rechteck definieren welches der vdr dann zeichnet ?
(die Elchi Skin hat viele dieser rectangles bzw . Ellipsen und dies
finde ich subjektiver schneller als Skins mit vielen image-Bitmaps)
- Möglichst wenig grosse Bilder oder besser mehrere kleine ?

Gibt es eine Möglichkeit mit text2skin herauszufinden, wie lange für eine
Anzeige benötigt wird ?

Könnte man debug Meldungen mit Zeiten einbauen um die Geschwindingkeit
zu messen - wenn ja in welcher Datei / Funktion müsste das sinnvollerweise
geschehen ?

Weiterhin habe ich festgestellt, dass in einigen Skins der Bereich in dem
das image gezeichnet werden soll (x1,y1,x2,y2) teilweise größer definiert ist
als das image von den Abmessungen her gross ist.

Kostet dies Performance ? Ich kann mir vorstellen, das der ARM-Prozessor
auf der DVB-Karte nicht der schnelleste ist beim neuzeichen des OSDs....

Bin für jeden Hinweis dankbar....

Gruss,
Gromit

@The Lord of Jaxom

Ma ne kleine zwischenfrage:

Der AustrianCoder arbeitet ja an nem MPEG-OSD (zugegebener maßen nur für DXR3-Nutzer), wird es dafür auch noch was geben ?
Ich meine damit das man dann doch auf diesen ganzen Background-Kram (für mich ziemlich kompliziert) verzichten kann, oder ?
Man erstellt einfach per Textdatei das OSD und das wird vollfarben gerendert ...

Also praktisch meine ich damit gibts dann ne ""einfache"" Möglichkeit nen Skin zu erstellen ...ohne diese ganzen "komplizierten" Farb und Rechenexempel.

Oder gibt da eventl. mal ne kooperation zwischen euch beiden ?

MFG
Marco

LordJaxom frag doch mal Klaus oder Werner (AC3Firmware), oder du unterschreibst eine NDA und kannst selber an der Firmware arbeiten.

mbc:

Das osd via ffmpeg wird es am Anfang nur fürs dxr3-plugin geben, da ich nur eine Budget DVB und eben eine Dxr3 habe. Zur Zeit ist das ffmpeg basierte Menü auf Eis, da das Dxr3-Plugin zur Zeit Vorrang hat. Viel würde für das fertigstellen von meinem Code net fehlen.

Wenn aber alles stable läuft, würde ich gerne Klaus davon überzeugen, dass das mpeg OSD direkt in den VDR kommt

fyi, kls hat aufm letzen VUMM! rle schon angesprochen, das wird definitiv kommen.

-- randy

Hi,
LordJaxom: Was genau bringt diese RLE-Komprimierung im Endeffekt?
-mehr Farben?
-geht damit auch ein Vollfarben-OSD in Vollbildgröße (bei ungemoddeten Karten)
-schnellerer Bildaufbau?

hab mal ein wenig gegoogelt, das Verfahren hört sich auf jeden Fall effektiv an.
mfg maz

maz

rle = Run-Length Encoding

Und hier ein kleiner Text was rle genau ist:

Zitat

Run-length encoding is a data compression algorithm that is supported by most bitmap file formats, such as TIFF, BMP, and PCX. RLE is suited for compressing any type of data regardless of its information content, but the content of the data will affect the compression ratio achieved by RLE. Although most RLE algorithms cannot achieve the high compression ratios of the more advanced compression methods, RLE is both easy to implement and quick to execute, making it a good alternative to either using a complex compression algorithm or leaving your image data uncompressed.

RLE works by reducing the physical size of a repeating string of characters. This repeating string, called a run, is typically encoded into two bytes. The first byte represents the number of characters in the run and is called the run count. In practice, an encoded run may contain 1 to 128 or 256 characters; the run count usually contains as the number of characters minus one (a value in the range of 0 to 127 or 255). The second byte is the value of the character in the run, which is in the range of 0 to 255, and is called the run value.

Uncompressed, a character run of 15 A characters would normally require 15 bytes to store:

AAAAAAAAAAAAAAA

The same string after RLE encoding would require only two bytes:

15A

The 15A code generated to represent the character string is called an RLE packet. Here, the first byte, 15, is the run count and contains the number of repetitions. The second byte, A, is the run value and contains the actual repeated value in the run.

A new packet is generated each time the run character changes, or each time the number of characters in the run exceeds the maximum count. Assume that our 15-character string now contains four different character runs:

AAAAAAbbbXXXXXt

Using run-length encoding this could be compressed into four 2-byte packets:

6A3b5X1t

Thus, after run-length encoding, the 15-byte string would require only eight bytes of data to represent the string, as opposed to the original 15 bytes. In this case, run-length encoding yielded a compression ratio of almost 2 to 1.

Long runs are rare in certain types of data. For example, ASCII plaintext seldom contains long runs. In the previous example, the last run (containing the character t) was only a single character in length; a 1-character run is still a run. Both a run count and a run value must be written for every 2-character run. To encode a run in RLE requires a minimum of two characters worth of information; therefore, a run of single characters actually takes more space. For the same reasons, data consisting entirely of 2-character runs remains the same size after RLE encoding.

In our example, encoding the single character at the end as two bytes did not noticeably hurt our compression ratio because there were so many long character runs in the rest of the data. But observe how RLE encoding doubles the size of the following 14-character string:

Xtmprsqzntwlfb

After RLE encoding, this string becomes:

1X1t1m1p1r1s1q1z1n1t1w1l1f1b

RLE schemes are simple and fast, but their compression efficiency depends on the type of image data being encoded. A black-and-white image that is mostly white, such as the page of a book, will encode very well, due to the large amount of contiguous data that is all the same color. An image with many colors that is very busy in appearance, however, such as a photograph, will not encode very well. This is because the complexity of the image is expressed as a large number of different colors. And because of this complexity there will be relatively few runs of the same color.

Alles anzeigen

Und sowas hat das DXR3-Plugin schon, damit man größere OSD's an die Karte schicken kann

Ok,
soweit verstanden. Heißt das dann, das ich effektiv viel mehr Daten in den Cache bekomme? Dann würde das OSD ja auch deutlich mehr Farben bekommen könnnen als bisher, besonders bei Vollbild-Darstellungen. Oder kann das OSD ohnehin nicht so viele Farben im Vollbild darstellen, egal wieviel Platz noch im Cache ist?

maz

Durch RLE wird nur die Übertragung schneller, weil effektiv weniger Daten durch den lahmen DPRAM geschautfelt werden müssen.

Der DSP packt das dann wieder aus (wenn es seine Firmware mal kann) und steckt es in den OSD-Speicher, da bleibts dabei: je nach "Vereinbarung" 1,2,4 oder 8 Bit pro Pixel.

Kurz, mehr Speed, sonst nichts.