Ausgabeplugins und Pixmaps ausserhalb des OSD

louis · 9. Mai 2015

Moin,

dieses Posting ist insbesondere an Autoren von Ausgabeplugins wie Reufer und Johns gerichtet...aber natürlich sind alle eingeladen, in die Diskussion einzusteigen

Ich habe ja begonnen, im Skindesigner die Möglichkeit zu implementieren, Pixmaps in das OSD "hereinfliegen" zu lassen. Dazu definiere ich den ViewPort der Pixmaps entsprechend zuerst mit Koordinaten außerhalb des sichtbaren OSD Bereichs und verschiebe die Position der Pixmaps dann entsprechend in einer Schleife, bis die Pixmaps am Ende der Schleife an ihrer Zielposition gelandet sind. Da hierbei meistens die Pixmaps am Rand des OSD liegen, sind die Koordinaten der Pixmaps (also der x und y Wert des Viewports) dabei natürlich auch ausserhalb des sichtbaren OSD Bereichs.

Das klappt so weit auch ganz ok, jedoch gibt es dabei einige Probleme, die wohl darauf zurückzuführen sind, dass die Positionierung von Pixmaps außerhalb des OSD in den Ausgabeplugins bzw. den benutzten Bibliotheken der Ausgabeplugins nicht vorgesehen ist bzw. nicht entsprechend behandelt wird. Erst mal einige Fakten, die mir bei meinen bisherigen Aktivitäten aufgefallen sind:

- ich teste nur mit softhddevice@nvidia-vdpau
- Pixmaps links (negativer x Wert für den Viewport), rechts (x Wert > OSD Breite) und unterhalb (y Wert > OSD Höhe) des sichtbaren OSD Bereichs funktionieren prima.
- Sobald eine Pixmap einen negativen y Wert hat (also teilweise "oberhalb" des sichtbaren OSD liegt), wird gar kein OSD mehr angezeigt.
- softhddevice stürzt anscheinend beim Löschen des OSD in einigen Fällen ab (bei mir passiert das nicht): Backtrace dazu siehe hier, dort sind Pixmaps unterhalb des schbaren OSD Bereichs gezeichnet worden.
- wie sich das ganze z.B. auf dem Raspi verhält weiss ich nicht, hierzu gabb es noch keine Rückmeldung

Ich hätte den folgenden Vorschlag zu unterbreiten: wäre es möglich, wenn die Ausgabeplugins im Falle eines TrueColor OSD die Pixmaps mit dem sichtbaren OSD Bereich zu "clippen"? Also einfach die Pixmaps, die komplett ausserhalb des OSD Bereichs liegen, gar nicht zu beachten, und die Pixmaps, die nur teilweise ins OSD hineinragen, nur das sichtbare Rechteck zeichnet. Soweit ich das sehe, benutzen Ausgabedevices Obekte der Klasse cPixmapMemory zur Ausgabe, über die Funktion "const uint8_t *Data(void)" kommt man ja an die einzelnen Pixel rann. Dann sollte es doch nicht großartig komplex oder performancefressend sein, vor der Ausgabe das clipping durchzuführen. Oder stelle ich mir das zu einfach vor?

Danke schonmal für die Kommentare...ciao Louis

S:oren · 9. Mai 2015

Nicht vergessen, es muessten (hoechstwahrscheinlich) auch die dvb[sh]ddevice-Plugins angepasst werden (benutzt noch jemand xineliboutput, oder sonstige Ausgabeplugins?).
Nach der letzten "erfolgreichen" "Diskussion" um die Pixmapgroesse wuensche ich schon mal viel Erfolg fuer diesen Vorstoss...

Gruss,
S:oren

louis · 9. Mai 2015

Moin,

klar, am besten wäre es wenn es alle Ausgabeplugins "richtig" machen...wenn es so richtig ist

Wenn dem nicht der Fall wäre, würden die Skins, die das Feature entsprechend benutzen, mit den Ausgabeplugins, die es nicht unterstützen, inkompatibel...

Ciao Louis

reufer · 9. Mai 2015

Zitat von louis

Ich hätte den folgenden Vorschlag zu unterbreiten: wäre es möglich, wenn die Ausgabeplugins im Falle eines TrueColor OSD die Pixmaps mit dem sichtbaren OSD Bereich zu "clippen"? Also einfach die Pixmaps, die komplett ausserhalb des OSD Bereichs liegen, gar nicht zu beachten, und die Pixmaps, die nur teilweise ins OSD hineinragen, nur das sichtbare Rechteck zeichnet.

Das ist durch das OSD-API des VDR eigentlich so vorgesehen und ist vom rpihddevice auch so implementiert. Ich habe zum testen des Highlevel-OSDs versuchsweise Pixmaps übers OSD fliegen lassen und das hat auch funktioniert. Deine Erweiterung sollte also mit dem rpihddevice funktionieren, auch wenn ich das noch nicht getestet habe. Falls es Probleme gibt, her damit!

Gruss
Thomas

kls · 9. Mai 2015

reufer: Ich wollte dir gerade eine Email schicken, erhielt sie aber zurück mit der Meldung

Code

----- The following addresses had permanent fatal errors -----
<thomas@reufer.ch>
    (reason: 554 5.7.1 Service unavailable; Client host [88.198.76.220] blocked using b.barracudacentral.org)


   ----- Transcript of session follows -----
... while talking to mail.reufer.ch.:
>>> DATA
<<< 554 5.7.1 Service unavailable; Client host [88.198.76.220] blocked using b.barracudacentral.org
554 5.0.0 Service unavailable
<<< 554 5.5.1 Error: no valid recipients

Alles anzeigen

Klaus

CafeDelMar · 10. Mai 2015

Zitat von kls

(reason: 554 5.7.1 Service unavailable; Client host [88.198.76.220] blocked using b.barracudacentral.org)

Hallo Klaus!

Das liegt daran, dass Dein Mailserver in zwei Anti-SPAM-Datenbanken als SPAM-Versender gelistet ist und Reufers Mailserver Deinen daher blockt.
Falls Die Sicherheitslücke geschlossen wurde, kannst Du Dich aus den Datenbanken wieder austragen lassen.

Beste Grüße,
CafeDelMar

reufer · 10. Mai 2015

Zitat von S:oren

Nach der letzten "erfolgreichen" "Diskussion" um die Pixmapgroesse wuensche ich schon mal viel Erfolg fuer diesen Vorstoss...

Die maximale Grösse einer Pixmap hat ja mit deren Position nichts zu tun und sollte eigentlich unabhängig von den vorhandenen Ressourcen sein.

Nichtsdestotrotz finde ich solche Diskussionen enorm wichtig. Nur mit einem gemeinsamen Verständnis bleiben die verschiedenen Plugins untereinander kompatibel und machen den VDR zu dem was er ist!

Zitat von kls

reufer: Ich wollte dir gerade eine Email schicken

Schick' mir doch eine PM über das Portal.

Gruss
Thomas

kls · 10. Mai 2015

Zitat von CafeDelMar

Hallo Klaus!

Das liegt daran, dass Dein Mailserver in zwei Anti-SPAM-Datenbanken als SPAM-Versender gelistet ist und Reufers Mailserver Deinen daher blockt.
Falls Die Sicherheitslücke geschlossen wurde, kannst Du Dich aus den Datenbanken wieder austragen lassen.

Seltsam ist nur, daß ich bis vor kurzem Thomas unter dieser Email-Adresse problemlos erreichen konnte, und mein Server definitiv kein SPAM verschickt. Es gibt also keine Sicherheitslücke, die zu stopfen wäre.

Ich habe die IP-Nummer jetzt mal bei http://barracudacentral.org freischalten lassen.
Du hast von *zwei* Anti-SPAM-Datenbanken gesprochen, welches wäre denn die zweite?

Klaus

kls · 10. Mai 2015

Zitat von reufer

Schick' mir doch eine PM über das Portal.

PM über das Portal nutze ich nicht.

Was ich dich fragen wollte war, ob du das evtl. im osddemo Plugin eingebaut hast als Testfall?
Wenn ja (oder wenn du es einbauen magst ;-), könntest du es mir dann bitte
schicken, damit ich das auch mit der TT S2-6400 testen kann?

Bzgl. der Blacklist: hast du da was seit dem 3.5.2015 geändert? An dem Tag konnte ich nämlich noch Emails an dich schicken.

Klaus

CafeDelMar · 10. Mai 2015

Zitat von kls

Du hast von *zwei* Anti-SPAM-Datenbanken gesprochen, welches wäre denn die zweite?

Das wäre dann diese hier: http://www.sorbs.net/

CafeDelMar

EDIT: @Mods: Da das ja nichts mit dem eigentlichen Thema zu tun hat, könnte man das ja eventuell in ein neues Thema verschieben.

reufer · 10. Mai 2015

Zitat von kls

Was ich dich fragen wollte war, ob du das evtl. im osddemo Plugin eingebaut hast als Testfall?
Wenn ja (oder wenn du es einbauen magst ;-), könntest du es mir dann bitte
schicken, damit ich das auch mit der TT S2-6400 testen kann?

Ich muss mich korrigieren: Ich habe nicht Pixmaps sondern Images rumfliegen lassen, und zwar die gecachten - sollte aber genau so gut mit den Pixmaps funktionieren. Das war quasi eine erweiterte Version des Codes, den ich dir fürs osddemo-Plugin bereits geschickt habe. Allerdings war das nicht viel mehr als ein "dirty hack", weshalb ich das wieder rückgängig gemacht habe. Ich habe das nur kurz mit deaktivierter GPU-Beschleunigung getestet, aber das war nicht viel mehr als eine Diashow und deshalb unbrauchbar.

Wenn du darauf bestehst, könnte ich das aber in einer ruhigen Minute nochmals implementieren…

Zitat von kls

Bzgl. der Blacklist: hast du da was seit dem 3.5.2015 geändert? An dem Tag konnte ich nämlich noch Emails an dich schicken.

Dazu müsste ich meinen Provider befragen, ich betreibe den Server nicht selber.

Gruss
Thomas

kls · 10. Mai 2015

Zitat von CafeDelMar

Das wäre dann diese hier: http://www.sorbs.net/

Danke. Ich hasse diese Blacklists, weil sie meist mehr schaden als nutzen. Bei SORBS muß man doch tatsächlich einen Account anlegen, um eine IP delisten zu lassen! Weil ich ja sonst nichts zu tun habe... Und der Grund für den Eintrag liegt offensichtlich vier Jahre zurück!
Lauter Deppen...

Zitat

@Mods: Da das ja nichts mit dem eigentlichen Thema zu tun hat, könnte man das ja eventuell in ein neues Thema verschieben.

Wäre vielleicht nicht verkehrt. Sorry, daß ich das hier reingebracht habe. Meinetwegen können auch alle Postings, die das Blacklisting betreffen, wieder gelöscht werden.

Klaus

kls · 10. Mai 2015

Zitat von reufer

Wenn du darauf bestehst, könnte ich das aber in einer ruhigen Minute nochmals implementieren…

"Bestehen" tue ich auf gar nichts ;-).

Aus API-Sicht ist es (wie du schon richtig erwähntest) absolut zulässig, negative Y-Werte zu verwenden, daher hätte ich das halt schnell mit der TT-S2 6400 getestet, wenn du da Code parat gehabt hättest. Macht aber nichts, wenn das nicht der Fall ist.

Klaus

louis · 10. Mai 2015

Moin,

Zitat von kls

Aus API-Sicht ist es (wie du schon richtig erwähntest) absolut zulässig, negative Y-Werte zu verwenden,

na das finde ich ja schonmal prima, dass du das so bestätigst

Ciao Louis

S:oren · 10. Mai 2015

Zitat von reufer

Die maximale Grösse einer Pixmap hat ja mit deren Position nichts zu tun und sollte eigentlich unabhängig von den vorhandenen Ressourcen sein.

Das sehe ich genau so.

Zitat von reufer

Nichtsdestotrotz finde ich solche Diskussionen enorm wichtig. Nur mit einem gemeinsamen Verständnis bleiben die verschiedenen Plugins untereinander kompatibel und machen den VDR zu dem was er ist!

Auch hier meine volle Zustimmung! Deshalb fand ich es ja so befremdlich, dass ich statt einer Antwort auf meine vorgebrachten Argumente zum Thema Pixmapgroesse einen "Tritt in den Hintern" bekommen habe. Eine Diskussion war nicht erwuenscht. Aber schoen, wenn es hier besser laeuft...

Gruss,
S:oren

johns · 11. Mai 2015

Zitat von louis

Moin,

na das finde ich ja schonmal prima, dass du das so bestätigst

Dann werde ich es wohl im SoftHdDevice Plugin einbauen müssen.
Da werde ich viel umbauen müssen, da ich nur von ganzen Pixmaps ausgegangen bin und daß der Highlevel bereits abschneidet.

Johns

reufer · 11. Mai 2015

Zitat von johns

Da werde ich viel umbauen müssen, da ich nur von ganzen Pixmaps ausgegangen bin und daß der Highlevel bereits abschneidet.

So wie ich das sehe, nutzt softhddevice ja die Renderfunktionen des VDR. Da musst du höchstens die Teile ausserhalb des OSDs abschneiden, das wäre dann maximal eine zusätzliche Zeile Code…

Gruss
Thomas

kls · 11. Mai 2015

Mit den im Core-VDR implementierten Pixmaps sollte es möglich sein, eine Pixmap an einen beliebigen Aufhängepunkt zu setzen.
Falls das nicht funktioniert, wäre es ein Bug und müsste im Core behoben werden. Wenn jemand hierfür ein kleines Testszenario in das osddemo Plugin einbauen könnte, wäre das nett. Den Bug würde ich dann schon fixen.

Klaus

louis · 11. Mai 2015

Moin,

Zitat von johns

Dann werde ich es wohl im SoftHdDevice Plugin einbauen müssen.
Da werde ich viel umbauen müssen, da ich nur von ganzen Pixmaps ausgegangen bin und daß der Highlevel bereits abschneidet.

was genau meinst du mit "der Highlevel bereits abschneidet."? Den VDR selbst? Wäre natürlich auch eine Option, wenn der VDR an die tatsächliche OSD Größe herankommen würde. Oder kann er das?

Ich finde es auf jeden Fall prima, dass dem Thema Aufmerksamkeit geschenkt wird

Ciao Louis

johns · 11. Mai 2015

Ich habe mich damit nicht näher beschäftigt und habe eigentlich nur den Beispielcode aus dem Header genommen.

Code

///<  LOCK_PIXMAPS;
       ///<  while (cPixmapMemory *pm = dynamic_cast<cPixmapMemory *>(RenderPixmaps())) {
       ///<        int w = pm->ViewPort().Width();
       ///<        int h = pm->ViewPort().Height();
       ///<        int d = w * sizeof(tColor);
       ///<        MyOsdDrawPixmap(Left() + pm->ViewPort().X(), Top() + pm->ViewPort().Y(), pm->Data(), w, h, h * d);
       ///<        DestroyPixmap(pm);
       ///<        }
       ///<
       ///< If a plugin uses a derived cPixmap implementation, it needs to use that
       ///< type instead of cPixmapMemory.

Alles anzeigen

Hier bin ich davon ausgegangen, daß die Pixmaps zugeschnitten und passend sind.
Du kannst -DOSD_DEBUG aktivieren umzusehen, welche Pixmaps wo gezeichnet werden sollen.

Eine einfache OSD-Demo die dies verwendet, wäre nicht schlecht.

Johns

Ausgabeplugins und Pixmaps ausserhalb des OSD

Jetzt mitmachen!

Teilen