Softdevice mit DirectFB: kein Video!

  • Schläfst Du eigentlich auch mal?
    Eigentlich ist das ein kompletter Rechner, den ich im meinem Projekt bei der alten Firma (Heidelberger Druckmaschinen) entwickelt habe. Durch das verwendete ETX-Modul von Kontron, welches schon alle relevanten Chips etc. enthält (also Prozessor, Chipsatz, Speicher-Slot, etc.), beschränkte sich unsere Arbeit auf das Base-Board, auf welches das ETX-Modul aufgesteckt wird und welches eigene Erweiterungen enthält, sowie auf Gehäuse, Kühlung, Spannungsversorgung etc. Bootet von CompactFlash.
    Das Rechner ist ziemlich kompakt (ca. 30x20x15 cm) und komplett passiv gekühlt (kein Lüfter!). Spezifiziert bis zu einer Umgebungstemperatur von 60 Grad.
    Stromverbrauch: 1 A bei Volllast an 24V. 8)
    Bilder später.


    [edit] Wenn ich's mir recht überlege, könnte ich den Rechner eigentlich auch durchlaufen lassen, bei dem Stromverbrauch. Dann wäre mein Client immer sofort verfügbar... :D

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

    2 Mal editiert, zuletzt von hubermat ()

  • Juhuuu,
    es gibt ein Bild! Bei 85% idle :D Erstmal vielen Dank für den Patch und alle Tips!!


    Zwei Punkte sind aber noch verbesserungwürdig.
    1. Das OSD ist voll opaque
    Logisch, da der OSD Layer kein Alphablending kann. Aber: um das OSD herum ist das Video-Bild zu sehen (color-keying?). Dann müßte es doch auch möglich sein, die Hintergrundfarbe des OSD generell auszublenden (sprich: nur Schrift und farbige Balken etc. werden angezeigt).


    2. Das Aspektratio
    Ich habe mal eine Serie von Bildern eingefügt. Sie zeigen alle die gleiche Szene von einem Film auf Arte. Der Film ist in Cinemascope o.Ä., auf alle Fälle aspect > 16:9, gut zu erkennen an den breiten schwarzen Balken beim ersten Bild (von meinem 4:3 Fernseher). Das Senderlogo ist auch gut zu sehen, das Film-Bild ist vertikal zentriert. Achtung, nicht verwechseln: dieses Bild ist von meinem anderen VDR mit DXR3-Karte!
    [Blockierte Grafik: http://www.jazzgames.com/4zu3TV.jpg]


    Die anderen Bilder sind von meinem 16:9-TFT (1280x768 Pixel, also nicht ganz 16:9) und dem VDR mit Softdevice.
    Zunächst das Bild mit Softdevice-Aspectration 4:3. Zu erkennen ist, daß der Video-Layer die volle Breite belegt, aber in der Höhe unten und oben Platz läßt (gleichmäßig). Das dunke Grau ist das Schwarz vom Video-Layer. Außerdem fällt auf, daß das Film-Bild nicht mehr vertikal mittig sitzt, unten ist also etwas abgeschnitten.
    [Blockierte Grafik: http://www.jazzgames.com/4zu3.jpg]


    Das nächste Bild ist mit aufgeschaltetem OSD.
    [Blockierte Grafik: http://www.jazzgames.com/osd_4zu3.jpg]


    Wenn ich im Softdevice-Setup zu Aspect "default" wechsele, siehts so aus:
    [Blockierte Grafik: http://www.jazzgames.com/osd_default.jpg]


    Und bei Aspect "16:9":
    [Blockierte Grafik: http://www.jazzgames.com/osd_16zu9.jpg]


    Noch ein Detail: ich bekomme immer die Ausgabe
    [dfb] (re)configuring Videolayer to 720 x 576 (720x496).


    Mein Wunsch wäre natürlich, bei 4:3 die volle Höhe zu nutzen und rechts und links schwarze Balken, bei 16:9 die volle Breite und oben und unten abgeschnitten...


    Gruß,
    Matthias

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

    2 Mal editiert, zuletzt von hubermat ()

  • Schön ist das ja nicht. Da habe ich einige Fragen:
    - Wie sehen die Messages in der syslog aus wenn skaliert wird ?
    - Was hast Du an intelfb modifiziert (diff) ?
    - Gibt es neben /dev/fb0 auch noch /dev/fb1 ?
    - Wenn ja wie sieht dort die Auflösung aus ?


    Compilier doch mal intelfb mit REGDUMP (intelfb.h). Dann sieht man wie die Auflösungen von pixel port A und B sind.

  • So, zu den Fragen:


    - Messages in syslog: ich habe eine Aufnahme abgespielt, und im OSD zweimal ein anderes Aspect-Ratio gewählt. Ausgabe in syslog:


    An der Kommando-Zeile (von der aus ich gestartet habe) gibt es nur immer wieder:

    Code
    [surface capabilities] videoSurface: videoonly double-buffered flipping PixelFormat = 0x08100609 
    [dfb] (re)configured 0x08100609
    YaEPG Window open 2
    [dfb] (re)configuring Videolayer to 720 x 576 (720x496)
    -- using: PIPE_A


    - Modifikationen an intelfb:
    Hiermit wird die Überprüfung abgeschaltet, ob DVO bzw. LVDS verwendet wird:

    Code
    diff drivers/video/intelfb/intelfbdrv.c /opt/nfsroot/scu/usr/src/linux/drivers/video/intelfb/intelfbdrv.c
    792c792,793
    <       if (dvo) {
    ---
    >       /* was: if (dvo) */
    >       if (0) {


    Und hiermit wird der PIPE_B der Vorzug gegenüber PIPE_A gegeben (der #if 0-te Teil ist nicht relevant, Ergebnis ist dasselbe):


    - /dev/fb1 gibt es nicht.


    - REGDUMP (der unmittelbar von softdevice: videoout okay):


    Soweit.
    Gruß,
    Matthias

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

  • So zu dem Problem mit der Skalierung kann ich Dir wohl weiterhelfen. Der DirectFB-Treiber für die Intel-Chips unterstützt wohl nicht SetSourceRectangle(). Dann mal bitte in der config.h,

    Code
    #define HAVE_SetSourceLocation          1

    auf

    Code
    #define HAVE_SetSourceLocation          0

    umändern. Nicht wundern über den Namensunterschied, das hat historische Gründe. Die HTOTAL und VTOTAL Werte hatten mich zwar auch aus diesem Grund interessiert, das ist aber nun hinfällig (pipe A ist auf 640x480 und pipe B auf 1280x768 konfiguriert).
    Mit dem opaque OSD bin ich noch ratlos.

  • Super, ich habe jetzt ein Bild in voller Höhe! :welle


    Was ich noch nicht so richtig verstanden habe, ist, nach welcher Heuristik das Bild wie skaliert wird.


    Das wäre zunächst "Screen Aspect". Das ist bei mir (1280x768) 15:9. Dabei wird das Bild dann hochskaliert und manchmal sind da schwarze Balken links und rechts und manchmal nicht.


    Die Skalierung wechselt offensichtlich dynamisch ("new Aspect detected 1.555556" oder "new Aspect detected 1.777778"). Wer detectet da was?


    Eigentlich möchte ich gerne, daß das normale PAL Fernsehbild (720x576?) entweder auf die volle Display-Höhe gleichmäßig skaliert wird (=956x768, entspricht 4:3 mit schwarzen Balken links und rechts) oder auf die volle Display-Breite (=1280x1024, also fällt oben und unten etwas weg).


    Uuups, gerade nachgerechnet: 720/576 = 1.25 = 5:4. Langsam blicke ich nicht mehr durch...


    Vielleicht kannst Du da ein wenig Licht reinbringen?


    Vielen Dank und Gruß,
    Matthias


    P.S. und das OSD-"Problem" (kann man eigentlich gar nicht so nennen) existiert weiterhin...

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

  • Zitat

    Was ich noch nicht so richtig verstanden habe, ist, nach welcher Heuristik das Bild wie skaliert wird.


    Das wäre zunächst "Screen Aspect". Das ist bei mir (1280x768) 15:9. Dabei wird das Bild dann hochskaliert und manchmal sind da schwarze Balken links und rechts und manchmal nicht.


    Die Skalierung wechselt offensichtlich dynamisch ("new Aspect detected 1.555556" oder "new Aspect detected 1.777778"). Wer detectet da was?


    Das kommt durch einen Patch von Roland, der Black-Border-Detection macht. Ist nicht in softdevice-cvs.

    Zitat

    Eigentlich möchte ich gerne, daß das normale PAL Fernsehbild (720x576?) entweder auf die volle Display-Höhe gleichmäßig skaliert wird (=956x768, entspricht 4:3 mit schwarzen Balken links und rechts) oder auf die volle Display-Breite (=1280x1024, also fällt oben und unten etwas weg).


    Uuups, gerade nachgerechnet: 720/576 = 1.25 = 5:4. Langsam blicke ich nicht mehr durch...


    Laß Dich hier nicht irreführen. Die Pixels die im Video sind, sind nicht quadratisch. Die Pixels des LCDs sind quadratisch. Skaliert wird im Verhältnis von Source-Aspect-Ratio zu Display-Aspect-Ratio (die 720/576 sind 4:3). Du könntest Deine Geometrie auf 16:9 stellen, dann würde zwar 16:9 bei Dir ohne Streifen dargestellt aber leicht verzerrt.

    Zitat

    P.S. und das OSD-"Problem" (kann man eigentlich gar nicht so nennen) existiert weiterhin...


    Da bin ich immer noch auf der Suche. Kannst Du Xorg auf das System bringen ? Da gibt es einiges an Behandlungen der Pipes.
    Was mich nur wundert: bei Dir ist Video unterhalb des OSDs zu sehen, bei mir war Video oberhalb des OSDs (ohne Colorkeying).
    Du könntest mal die Zeile

    Code
    regs->OCMD    = OVERLAY_ENABLE;

    in

    Code
    regs->OCMD    = OVERLAY_ENABLE | 0x80000000;

    ändern (File i830_overlay.c, Zeile ~622).

  • Neue Ergebnisse:


    - Black-Border-Patch habe ich rausgenommen, jetzt habe ich bei Screen Aspect "15:9" ein schönes 4:3-Bild (mit schwarzen Streifen links und rechts) auf meinem TFT. So soll es sein. Allerdings wäre es schön, wenn ich dieses Bild jetzt proportional skalieren könnte, so daß es das ganze TFT ausfüllt (auch wenn dadurch oben und unten etwas vom Bild wegfallen würde). Gibt es da schon irgendetwas oder sollte ich da eine Setup-Einstellung erfinden?


    - die Änderung von regs->OCMD bringt leider nichts für das OSD :(


    - Xorg habe ich nicht auf meinem System drauf (hatte ich eigentlich auch nicht vor).


    Gruß,
    Matthias

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

  • Um ehrlich zu sein ich bin ja schon fast am Aufgeben. Was mich aber noch davon abhält ist die Tatsache, daß der Graphik-Layer bei Dir ja nicht den ganzen Video-Layer überdeckt. Wenn das OSD verschwindet wird der gesamte Bereich gelöscht; gezeichnet wird das OSD aber nur in einem Teilbereich.


    - Wie wirkt es sich aus wenn statt pixelformat ARGB nur RGB in der directfbrc angegeben wird ?
    - In SoftOsd.c in der Funktion ARGB_to_RGB32() den USE_MMX2 Teil auskommentieren und in
    dem dann verwendeten C Teil die Zeile dest[3]=GET_A(c); ebenfalls auskommentieren sodaß keine
    Alphakomponente geschrieben wird.


    Als letzte Möglichkeit bliebe dann nur noch Software OSD-Blending ebenfalls für dfb-out nachzuziehen.

  • Sodele, jetzt klappt's!


    - einfach nur in directfbrc ARGB zu RGB32 ändern bringt nichts


    - Patch in SoftOsd.c: ich habe jetzt ein halbtransparentes OSD (d.h. auch Text und Rahmen etc. sind halbtransparent). Bei meiner DXR3-Karte ist nur der Hintergrund des OSD halbtransparent, oder irre ich da? Gleichzeitige Änderung der directfbrc (siehe oben) bringt nichts weiter. Wie kann ich denn den Transparenz-Grad ändern?


    Vielen Dank, daß es schon so gut geht!
    Gruß,
    Matthias

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

  • Zitat

    Originally posted by hubermat
    - Patch in SoftOsd.c: ich habe jetzt ein halbtransparentes OSD (d.h. auch Text und Rahmen etc. sind halbtransparent). Bei meiner DXR3-Karte ist nur der Hintergrund des OSD halbtransparent, oder irre ich da? Gleichzeitige Änderung der directfbrc (siehe oben) bringt nichts weiter. Wie kann ich denn den Transparenz-Grad ändern?


    Da bin ich aber überrascht. Du hast also nur "dest[3]=GET_A(c);" auskommentiert, richtig ?
    Was ergibt sich wenn da "dest[3]=0;" steht ?


    Kannst Du von dem halbtransparenten OSD noch mal ein Bild machen (vor und nach dest[3] = 0 ) ?


    Und schließlich ist noch zu püfen ob die Transparenz nur global oder pixelbasiert ist.
    Dazu ist in video-dfb.c ungefähr in Zeile 1176 in der Methode GetOSDMode()
    HasAlpha = !OSDpseudo_alpha;
    auf
    HasAlpha = true;
    zu setzen.

  • So, neue Tests:
    1. Nur dest[3] auskommentieren (und MMX2-Code #if 0llen):

    Code
    -                        dest[3]=GET_A(c);
    +                        //dest[3]=GET_A(c);

    Ergebnis:
    [Blockierte Grafik: http://www.jazzgames.com/dest0.JPG]


    2. dest[3]=0 (und MMX2-Code #if 0llen):

    Code
    -                        dest[3]=GET_A(c);
    +                        dest[3]=0;

    Ergebnis (kein Unterschied, daher gleiches Bild ;) !):
    [Blockierte Grafik: http://www.jazzgames.com/dest0.JPG]


    3. HasAlpha = true und dest[3]=0 (und MMX2-Code #if 0llen):

    Code
    -                        dest[3]=GET_A(c);
    +                        dest[3]=0;
    ...
    -  HasAlpha=!OSDpseudo_alpha;
    +  HasAlpha = true; // HasAlpha=!OSDpseudo_alpha;

    Ergebnis:
    [Blockierte Grafik: http://www.jazzgames.com/HasAlpha.JPG]
    [Blockierte Grafik: http://www.jazzgames.com/HasAlphaClose.JPG]


    Ich habe dann auch nochmal einen Test gemacht, bei dem ich nur HasAlpha=true gesetzt habe. Ergebnis ist das gleiche wie bei 3.


    Gruß,
    Matthias


    P.S. Wenn ich den VDR wieder beende, kann ich ihn nicht erneut starten, softdevice bleibt bei der Initialisierung von DFB hängen (das selbe passiert mit jeder anderen DFB-Test-Applikation auch). Wenn ich den VDR nicht starte, kann ich die DFB-Applikationen beliebig oft starten und stoppen. Irgendeine Idee, was das sein könnte? Ich muß für jeden VDR Test-Run den Rechner neu starten...

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

  • Die Bilder von den Versuchen 1 & 2 sehen nach Global-Alpha aus. Die Bilder vom 3. Versuch gefallen mir schon besser, da das so etwa dem Colorkeying entspricht, bis auf den völlig transparenten Hintergrund.
    Wenn HasAlpha den Wert true hat, wird aber wieder eine andere Konvertierungsrutine aufgerufen. Also nicht die, in der Du die dest[3] Änderung gemacht hast. Aber wieso das diese Auswirkung hat ist mir schleierhaft, da ja eigentlich die gleichen Werte füs OSD geschrieben werden.


    In den Xorg-Treibern werden auch die SourceColorkey-Register auf null gesetzt.


    Die Zeile:
    regs -> SCLRKVH = regs -> SCLRKVL = regs -> SCLRKEN = 0;
    in i830_overlay.c vor dem Setzten der OVERLAY_PIPE_B einfügen.


    Die Änderung bzgl. HasAlpha sollte dann auch wieder rückgänig gemacht werden.



    Das mit dem Hängenbleiben hatte ich auch mal.
    Ist das neu bei Dir oder war das schon immer so ?
    Hast Du pixelformat wieder auf ARGB gesetzt ?


    Ich glaub Dir würde das OSD aus Deinen Versuchen 1 & 2 mit etwas weniger Transparenz besser gefallen, aber da müße noch mehr in DirectFB geändert werden und auch noch einiges in softdevice. Naja mal sehen.

  • Wenn ich die Zeile regs -> SCLRKVH = regs -> SCLRKVL = regs -> SCLRKEN = 0; reinnehme, passiert
    A.: opaques OSD, wenn ich SoftOSD.c gar nicht ändere (also keine Änderung zu früher)
    B.: opaques OSD und kein Video-Bild (sic!), wenn ich in SoftOSD.c den MMX2 Part rausnehme und dest[3]=0.


    Pixelformat ist bis auf den einen kurzen Test drei Postings weiter hinten immer auf ARGB.


    Das Hängenbleiben ist mir schon beim ersten Test mit softdevice aufgefallen. Seitdem habe ich das.


    Mit einem halbtransparenten OSD wäre ich schon zufrieden, wenn ich den Grad der Transparenz einstellen könnte.


    Wenn ich irgendwie mitdenken kann/soll, bitte sagen! Wie wäre es z.B. mit dem Ansatz vom 3. Versuch (colorkeying), nur daß man vorher einen halbtransparenten Hintergrund draufmalt ("blittet"?).


    Gruß,
    Matthias

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

  • Schlechte Neuigkeiten. Ich bin nochmal zurück auf den Patch-Stand, bei dem ich nur den MMX2-Teil auskommentiert habe. Ergebnis was das halbtransparente OSD.


    Ich habe mich die ganze Zeit gefragt, wie das überhaupt sein kann. Wenn meine Layer laut dfbinfo gar kein Alpha können, sondern nur dst-colorkeying, dann ist doch Halbtransparenz eigentlich gar nicht möglich (zumindest nicht über Layer), sondern das Video-Bild müßte "von Hand" mit dem OSD verrechnet werden (was aktuell wohl nicht erfolgt, denke ich).
    Ich habe jetzt bei genauerer Betrachtung festgestellt, daß das OSD gar nicht halbtransparent ist!!! Tatsächlich sah das nur aus der Entfernung so aus. Von Nahem betrachtet, ist das ein opaques OSD, bei dem jedes zweite horizontale Pixel das OSD zeigt, und das andere das Videobild...


    Wie geht's jetzt weiter? Was läßt sich denn (rein theoretisch) mit Destination Colorkeying so alles anstellen?
    Das Berechnen der OSD-Transparenz in Echtzeit (sprich: Verrechnung mit dem decodierten Live-Bild) wäre zu rechenintensiv, oder?


    Wenigstens ein Lichtblick: Das Hängenbleiben tritt nicht mehr auf. Frag mich nicht... :rolleyes:


    Gruß,
    Matthias

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

  • Zitat

    Originally posted by hubermat
    Schlechte Neuigkeiten. Ich bin nochmal zurück auf den Patch-Stand, bei dem ich nur den MMX2-Teil auskommentiert habe. Ergebnis was das halbtransparente OSD.


    Ich habe mich die ganze Zeit gefragt, wie das überhaupt sein kann. Wenn meine Layer laut dfbinfo gar kein Alpha können, sondern nur dst-colorkeying, dann ist doch Halbtransparenz eigentlich gar nicht möglich (zumindest nicht über Layer), sondern das Video-Bild müßte "von Hand" mit dem OSD verrechnet werden (was aktuell wohl nicht erfolgt, denke ich).


    Die Karte (Chipsatz) kann mehr als von DirectFB unterstützt wird, und wegen der ausschließlichen Verwendung der PIPE_B gibt es unbekannte Effekte, da es mal wieder für neuere Chips keine Informationen vom Hersteller gibt. Meine Infos basieren auf:
    http://dri.freedesktop.org/wiki/Intel
    Dort ist ein direkter Link zur Beschreibung vom i815.


    Zitat

    Ich habe jetzt bei genauerer Betrachtung festgestellt, daß das OSD gar nicht halbtransparent ist!!! Tatsächlich sah das nur aus der Entfernung so aus. Von Nahem betrachtet, ist das ein opaques OSD, bei dem jedes zweite horizontale Pixel das OSD zeigt, und das andere das Videobild...


    Jedes 2. Pixel. Das ist doch der Pseudo Mode. Das sollte aber nur für den "Hintergrund" gemacht werden.


    Du hast doch den Big-OSD-Patch von Roland drin ?
    Da gibt es diese Änderung für SoftOsd.h (grrr):

    Code
    -#define IS_BACKGROUND(a) (((a) < OPACITY_THRESHOLD) && ((a) > TRANSPARENT_THRESHOLD))
    +#define IS_BACKGROUND(a) (1)

    [Nachtrag:] sowie:

    Code
    // osd some constants and macros
    -#define OPACITY_THRESHOLD 0x9FLL
    +#define OPACITY_THRESHOLD 0x00LL

    [/Nachtrag:]
    Mach das _rückgänig_ !!.


    In seiner Vidix-Version setzt er in der Funktion GetOSDDimensions() Width und Height auf -1 (um eine Skalierung zu unterdrücken), ansonsten wird da die aktuelle Auflösung zurückgeliefert.


    Zitat

    Das Berechnen der OSD-Transparenz in Echtzeit (sprich: Verrechnung mit dem decodierten Live-Bild) wäre zu rechenintensiv, oder?


    Das geht. Das hatte ich auch schon ein paar Posts vor angedeutet "Software OSD-Blending". Bei mir funktioniert das auch schon teilweise für dfb-out, wenn die andere Skalierungsmethode gewählt ist (Stichwort HAVE_SetSourceLocation).


    Zitat

    Wenigstens ein Lichtblick: Das Hängenbleiben tritt nicht mehr auf. Frag mich nicht... :rolleyes:


    Schön.

  • Suuuppper!!! Der Pseudo-Mode funktioniert jetzt einwandfrei! :bounce1


    Jetzt werde ich nur noch an der Skalierung arbeiten, dann bin ich zufrieden.


    Wieso wird eigentlich in video-dfb eine Fernbedienung angelegt (und angelernt)? Macht das der VDR nicht selbst über z.B. lirc?


    Vielen Dank für Deine Hilfe,
    Matthias

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

  • Was ich unter "Skalierung" bezeichnet habe, gibt es natürlich schon längst! Nennt sich "Crop-Mode". Ich schäme mich in Grund und Boden...
    Ich bin mir allerdings ziemlich sicher, daß es keinen Crop-Mode für 15:9 gibt. Das werde ich jetzt dann doch noch selbst nachrüsten...

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

  • So nun muß ich noch mal dieses Thema aufgreifen.
    Die Änderungen in SoftOsd.c sollten alle zurückgesetzt werden.
    Für DirectFB hat ich einen neuen Patch, durch den die genutzte PIPE für den Videolayer in /etc/directfbrc gewählt werden kann.

    Code
    i8xx_overlay_pipe_b

    Das solltest du also in der driectfbrc eintragen.
    Das Basisverzeichnis für den Patch ist DirectFB.


    Zitat

    Wieso wird eigentlich in video-dfb eine Fernbedienung angelegt (und angelernt)? Macht das der VDR nicht selbst über z.B. lirc?


    So kann auf Eingaben reagiert werden, bevor vdr diese überhaupt mitbekommt. Der Cropmode kann so auf eine beliebige USERx Funktion gelegt werden.

  • Im SoftOSD.diff war nur der MMX2-Part ge-if 0-lt.
    Das habe ich jetzt wieder rausgemacht (also Original-SoftOSD.c) und Deinen DirectFB-Patch eingespielt. Ergebnis: kein Video-Bild.
    Dann habe ich den MMX2-Part wieder rausgemacht und siehe da - Video-Bild ist wieder da, mit dem "Pseudo-Alpha". Also alles wie vorher.
    Ich kann damit gut leben. Warum allerdings der MMX2-Part nicht funktioniert, würde mich schon interessieren...

    Server: Athlon XP 2000+, WinTV Nova-s, VDR 1.6.0-r2, streamdev-0.5.0_pre
    Client 1 "SCU": Pentium M 1.4Ghz, i855GM Grafik, diskless, VDR 1.4.1, streamdev-client, softdevice with DirectFB
    Client 2 "Epia": Via Epia M10000, diskless, VDR 1.3.17, dxr3, streamdev-client
    Client 3 "XBMC": Acer Aspire Revo R3600 (ION/Atom230), Ubuntu 9.04, XBMC svn pvr_testing

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!