Posts by wbreu

    Nabend Andreas,


    danke für die Anleitung, für die Akten:


    Fehler beim Kernel 2.6.39-rc3



    Soweit ich ergoogelt habe reicht ein Auskommentieren der Zeile.


    Die Ergebnisse gegen einen 2.6.38.3 bekommst du wenn der compile durch ist.


    Gruß
    Wolfgang

    Tach df,


    mal ne Rückmeldung, damit du siehst, dass sich deine Arbeit gelohnt hat.


    System: VDR-1.7.17, df-osd-handling-alter-vdpau-h264-decoder, xine-0.9.4-plugin und xine-ui (von gestern), Core-i3 mit GT430


    Zu 1. Jepp funzt einwandfrei
    Zu 2. Klappt in allen beschriebenen Details, inkl. Windowsscaling
    Zu 3. "i" erzeugt Einblendung in der GUI und funzt
    Zu 4 und 5. siehe System


    xineliboutput teste ich nicht im Moment.


    Spulen in allen Varianten funzt, Markenverschieben klappt, => wer Probleme beim Spulen hat mal den index der Aufnahme neu generieren.


    Verpixelungen beim Umschaltvorgang sind komplett weg, der alte Decoder scheint doch nicht so schlecht zu sein.


    Danke fürs Update!


    Gruß
    Wolfgang

    Moin,


    das will ich so nicht stehen lassen.

    Zu den Verpixelungen: Das ist halt die Wahl zwischen Pest und Cholera. Die Aussage von wbreu das das Problem gelöst ist, ist schlicht falsch. Man kann die Verpixelungen wegbekommen mit streamstart Patch, dafür funktionieren dann andere Sachen nicht, weswegen wir den nicht drin haben (lieber ein kosmetisches Problem als ein funktionales) , neue Hoffnung gibt der alternative vdpau Decoder, welche Probleme es damit gibt und wann die gefixt sind muss man dann sehen. Den jetzt gleich nach stable zu bringen bin ich strikt dagegen.


    Wenn du meinen obigen Post genau liest, habe ich davon geschrieben, dass sich das Umschaltverhalten (hinsichtlich Verpixellungen) schon länger ändern lässt. Und das ist Fakt, sowohl mit xineliboutput, als auch mit dem xine-plugin. Ein Mittel dazu ist/war der Stream-Start-Patch. Im übrigen steht da "z.B.". Es gibt noch/ein zwei andere Möglichkeiten, wie kleinere Puffer und aktueller Nvidia-Treiber oder eben das xine-Plugin.


    Dass durch den Stream-Start-Patch andere Nebenwirkungen da sind, steht nicht zur Diskussion, aber die hätte man Fixen können.


    Wenn ihr den Stream-Start weglasst und User das zur Sprache bringen, darf ja wohl der Hinweis dazu noch erlaubt sein.


    Um konkret zu sein, die Aussage von mir ist richtig gewesen, schreibst du ja selber im nächsten Satz.


    Also warum soll dann meine Aussage schlicht falsch sein?


    Manchmal muß man sich schon wundern, was alles interpretiert wird in einen Post, wenn nach den Verpixellungen beim Umschalten gefragt wird.


    Gruß
    Wolfgang

    Nabend,


    mal hier einen Status abgeben.


    Habe den Patch mal in die xine-lib von df vom 03042011 eingebaut, also altes OSD-Handling, da mir der neue Branch mit dem aktuellem OSD-Handling immer mit text2skin absemmelt, => das xine-frontend beendet sich mit einem xitk-Fehler. Mit skinenigmang gibts da keine Probleme.


    Ergebnisse des neuen Dekoders mit xine-plugin-0.9.3 und VDR-1.7.17 (das 0.9.4er hat ja das bekannte Problem mit dem OSD-Handling bei SD-Sendern und beim Cropping):


    - Sofort stabiles Bild nach dem Umschalten, ohne Verpixellungen


    - Spulen klappt vorwärts und rückwärts sauber und ohne Probleme (SD, HD-720, HD-1080i), keine Verpixellungen während dem Spulen und anschliessendem Anlaufen.


    - Umschaltvorgang schneller bis Bild da/angezeigt wird.


    - Der Patch lässt sich auch problemlos in ältere xine-lib-Versionen mit df-Patch einbauen.


    Gruß
    Wolfgang

    Nabend,


    das kann ich soweit bestätigen, das Deinterlacing bei SD/HD funzt soweit wie ebsi es beschrieben hat.


    Habe gerade auch mal wieder ein Update meiner Installation gemacht und mal wieder getestet.


    Doku der gesamten Geschichte wie immer auf meiner Homepage.


    Gruß
    Wolfgang

    Moin,


    du hast eine Mischmasch an möglichen xine-lib's auf deinem Rechner.


    Wenn du den nicht wegmachst, dann kommt es eben zu solchen Fehlern.


    Konkret, du baust xineliboutput gegen die
    build with xine-lib 1.1.90
    und dann später beim Aufruf wird:
    using xine-lib 1.1.18


    genutzt


    Bereinige dein System von allen xine-lib's und fang dann nochmal von vorne an mit den neuen xinelib/xineliboutput, dann brauchst du nicht neuinstallieren.


    Gruß
    Wolfgang

    Hi Zoolook,


    danke für den Patch, die Icons werden korrekt dargestellt und auch mit allen Umlauten gibts in allen Menüs keine Probleme mehr. Bei mir läuft ein Debian Squeeze mit UTF-8 mit graphlcd-0.1.9.


    Gruß
    Wolfgang

    Mahlzeit,


    da ja Amair (Andreas) in einem anderen Thread gebeten hat einen eigenen Thread für Anpassungen, Wünsche, Features, Vorschläge für die neue Version zu erstellen, fange ich mal hier an.


    Soweit es möglich ist, werde ich die Vorschläge hier im ersten Post stichpunktartig sammeln. Bitte nur Posten, wenn das wirklich zum Thema passt.


    - TrueColour-Unterstützung des Skins


    - Date/Time-Angaben komplett ausgeschrieben im Info-Menü


    - Logo/Icon-Darstellung in *png und/oder *jpg-Unterstützung => konfigurierbar


    - Größe der Senderlogos anpassbar, Bereich: Breite 275, Höhe 205


    - Fortschrittsbalken unter dem Senderlogo in der Länge konfigurierbar


    - Die Icons (rechts unten) sind skalierbar und passen sich der Größe des OSD's an.


    Ein komplettes Vollfarben-Senderlogo-Pack (ca. 3000 Stück) liegt hier in *.png auf der Platte, sowohl volltransparent, als auch mit weissem Hintergrund. Größe jeweils 268x200 Pixel.


    Gruß
    Wolfgang


    Mahlzeit Andreas,


    danke für deine Rückmeldung, na das freut mich doch, wenn du das umsetzen willst.


    Wenn du Tester brauchst, einen hast du schon....


    Im Moment kann das vdr-xine-plugin das "neue" OSD, bei xineliboutput wird daran gearbeitet.


    Ich mache mal einen neuen Thread auf, um die Wünsche zu sammeln.


    Keine_Ahnung , sorry, KLS baut die neuen OSD-Möglichkeiten in den VDR, im vdr-xine-Plugin ist es auch drinnen, und jetzt fehlt halt noch ein skin der es nutzt/nutzen kann, wenn du das nicht brauchst, oder Ängste hast, lass doch einfach die Finger weg.


    Ich sehe im Moment keine Ansätze, dass ein anderer Skin angepasst wird. Geschweige denn bereits daran gearbeitet wird. Oder arbeitet schon jemand an text2skin und "neuem" OSD-Handling?


    Als Denkanstoß, in anderen Umgebungen (Enigma 2 im Receiver-Bereich) gibt es einen Skineditor mit dem man schon lange keine Einschränkungen durch Farben im OSD hat, auch Icons, Bilder und dergleichen sind frei skalierbar, je nach Skingröße, ein großer Standard-Baukasten halt, mit eigener Skinneroberfläche zum Anpassen des Skins, mit Funktionen und Aussehen.


    Gruß
    Wolfgang


    Du kannst ja dann bei der "alten" Version bleiben...


    Gruß
    Wolfgang