[ANNOUNCE] Avards-Plugin 0.1.0 und 0.1.1-beta

Hmm, ich hab da mal ne Idee.
(Bzw. vermutlich ein Verständnisproblem und sowieso keine Ahnung, das merkt ihr aber jetzt direkt :schiel)

Folgendes:
Wieso gibt es nicht sowas wie eine globale Einstellung für die Auflösung?
Zumindest die immer weiter verbreiteten LCDs haben doch ne "echte" Auflösung des Panels, für "alte" Röhren gilt das ja irgendwie nicht.

Wenn diese nun konfigurierbar wäre (jeder trägt sich die Werte seines Geräts in ne Setupdatei ein), dann würde ich mir das nun wie folgt vorstellen, ich nenn das mal "mehrlagigen Ausgabepuffer":

a.) Die Wiedergabe vom VDR kennt die "Zielgröße", Plugins wie dieses AVARDS oder andere könnten ihr Bild drauf hin trimmen dass es möglichst formatfüllend dort rein passt.
Das wäre die "unterste Lage" des Ausgabepuffers.

b.) Wenn nun x-beliebige Sachen ins OSD gelegt werden, dann wissen diese ja ebenfalls die Zielgröße und können sich danach richten. Oder prozentual kleiner sein oder was immer sie wollen... (Aber es gäbe nie ne abgeschnittene Ausgabe weil das OSD zu groß wäre oder sowas...)
Das wäre die "obere Lage" des Ausgabepuffers.

c.) Die beiden Zwischenspeicher werden übereinander gelegt.
Von dort aus (bisher Software?) wird das neue, überlagerte Bild zum Ausgabedevice geschoben.

Klingt für mich total plausibel, aber vermutlich nur weil ich keine Ahnung habe

Mag mich jemand aufklären oder werde ich direkt gesteinigt

Hallo FireFly,

Zitat

Original von FireFly
2. Avards passt die Werte von Setup.OSDxyz an
+ alle Plugins arbeiten mit den angepassten Größen
o Avards muss die Originalgröße beim Shutdown zurückschreiben sonst ist das OSD beim Start ohne Avards vollkommen falsch
- es von einem Plugin in VDR-Setup geändert (evtl. nur im Main Thread möglich? siehe Post von triple955)
- nach einen Crash startet VDR evtl. mit der falschen Größe

Ich bin für lösung 2

Die probleme mit der falschen auflösung nach dem beenden / crash kann man lösen in dem man die einstellung von VDR "ignoriert" und in Avards die einstellung der maximalen größe einbaut. Damit kann avards beim starten immer die korrekte größe einstellen

Ich denke mal das größte problem dürfte sein ob die VDR-Setup einstellung (ohne VDR patch) im plugin geändert werden kann (stichwort main thread).

Ansonsten kann man naürlich auch beide lösungen implementieren und per setup oder abhängig vom skinnamen/skinplugin einstellen.

Gruß
Viking

Hi FireFly

Zitat

Original von FireFly

Dazu dient doch der "frontend has lock test" oder funktioniert der bei Dir nicht?

Ok, das war nicht ganz richtig von mir. Skaliert wird nur, wenn ein Kanal "richtiges" 16:9 ausstrahlt, also das was auch ohne das Plugin skaliert wird.

Zitat

Original von FireFly

Das habe ich ja von avards 0.0.6 übernommen. Mann kann die Verzögerung zwischen zwei Test (Poll) einstellen (mind. 80ms) und der Delay gibt an, wieviele identische Auswertungen es gegeben haben muß damit geschaltet wird. Damit ergibt sich die Gesamtverzögerung aus Poll x Delays.

Ok, danke für die Info.

Zitat

Original von FireFly

Da sage ich mal ganz pauschal: Das geht nicht, denn a) wüßte ich nicht wie Avards herausfinden soll ob grade ein Menü angezeigt wird und b) haben die meisten Fernseher ja auch noch eine Verzögerung. Außerdem gibts ja sowieso noch ein paar Designschwächen mit denen wir aberleben müssen, z.B.: man hat die Kanalanzeige (DisplayChannel) und hüpft einen Kanal weiter. Dann zoomt evtl. Avards, aber die Kanalanzeige bleibt ja offen und hat dann die falsche Größe ....

Also ob ein Menü offen ist sollte AFAIK (hab aber nur kurz gesucht) über zwei Möglichkeiten gehen:
1.) über cStatus: Hier könnte über OsdTitel und OsdProgramme festgestellt werden, dass ein Menü geöffnet wird und über OsdClear dass es wieder geschlossen wird. Problem hier dürfte wohl sein dass dann Plugins wie femon nicht berücksichtigt werden da sie keinen Titel setzen.

2.) über cOsd::IsOpen() müsste es eigentlich ohne Aufwand funktionieren und sollte alle Fälle berücksichtigen.

Also die Verzögerung am Fernseher wäre ja IMHO egal. Wenn AVARDS ein WSS schaltet und das ein wenig dauert macht das ja nichts. Das OSD ist richtig skaliert und wenn es dann erst (im schlimmsten Fall) eine Sekunde später richtig am Fernseher auftauch sollte das ja nicht so schlimm sein oder?

Das mit dem Zappen durch die Kanäle würde dann ja auch berücksichtigt, d.h. wärend dem Zappen wird das OSD nicht skaliert bzw. kein WSS ausgegeben. Erst wenn das OSD wieder geschlossen ist sollte wieder ein Signal kommen.

Zitat

Original von FireFly

Eigentlich ist ja das das schöne an Avards dass dass automatisch geht (Man verzeihe mir die vier das ein einem Satz) und das möchtest Du wieder ausgebaut haben? Dann müßte man zum aus-/einschalten sich jedesmal durch die komplette Reihe Menü->ein Menü->4:3 Menü->16:9 Menü->L14:9 Menü->L16:9 Menü->aus durchhangeln ....

Die Vorgabe im Hauptmenü wäre einfach ganz praktisch für z.B. Musiksender, denn da bringt das Umschalten (z.B. nur weil ein Titel eingeblendet wird) nicht sooo viel. Aber so wichtig ist das ganze auch nicht ...

Gruß,
Brougs78

Hallo FireFly / viking

Zitat

Original von FireFly
- es von einem Plugin in VDR-Setup geändert (evtl. nur im Main Thread möglich? siehe Post von triple955)

Zitat

Original von viking
Ich denke mal das größte problem dürfte sein ob die VDR-Setup einstellung (ohne VDR patch) im plugin geändert werden kann (stichwort main thread).

Nur zur Klarstellung: Ich möchte nicht mit Gewissheit behaupten, dass es nur aus dem Haupthread von VDR möglich ist, die OSD-Einstellung vom VDR-Setup zu ändern.

Als ich damals probehalber den Analyse-Teil von avards in mein SwitchOSDPos-Plugin gebastelt habe, war ich mir einfach nicht sicher, welche Auswirkungen es haben kann, wenn ich von einem Thread aus diese VDR-Einstellungen verändere. Ausserdem konnte ich nicht überblicken, welche Konsequenzen es auf VDR oder andere Plugins hat, wenn die OSD-Einstellungen geändert würden, wenn gerade ein OSD offen ist. Und da ich mir weiterhin nicht sicher war, ob ich cOsd::IsOpen() in einem Thread (eben dem Bildanalyse-Thread) aufrufen darf, habe ich mich eben für die defensivste Variante entschieden und die Abfrage, ob ein OSD offen ist und ggf. die Änderung der OSD-Position in MainThreadHook() gelegt.

Als Pseudocode sah mein MainThreadHook dann ungefähr so aus:

void MyPlugin::MainThreadHook()
{
  if (aktuelle Einstellungen != AnalyseThread.getOSDPos() && !cOsd::isOpen())
  {
    setze Setup.OSDxxx
    gebe WSS-Signal aus.
  }
}

Also wie gesagt: Da ich einfach nicht alle Auswirkungen überblicken konnte, habe ich mich für die aus meiner Sicht und nach meinem Kenntnisstand für eine defensive Variante entschieden. Mit etwas mehr Überblick über die Auswirkungen mag man zu einer anderen Beurteilung kommen.

Das nur zur Information.

bye, Alex

Hi nochmal!

Zitat

Original von FireFly
Es kristallisieren sich also jetzt zwei Vorgehensweisen für die angepasste OSD-Größe heraus:

• Avards stellt eine Service-Schnittstelle zur Verfügung mit den zum aktuellen Zoom passenden Menügrößen.
  + ohne Änderungen am VDR-Setup möglich
  - nur Plugins die die Größe bei Avards abfragen profitieren davon
  

  
  

• Avards passt die Werte von Setup.OSDxyz an
  + alle Plugins arbeiten mit den angepassten Größen
  o Avards muss die Originalgröße beim Shutdown zurückschreiben sonst ist das OSD beim Start ohne Avards vollkommen falsch
  - es von einem Plugin in VDR-Setup geändert (evtl. nur im Main Thread möglich? siehe Post von triple955)
  - nach einen Crash startet VDR evtl. mit der falschen Größe

Alles anzeigen

An und für sich ist die Service-Schnittstelle sicherlich eine elegante Lösung und für Plugins nicht ganz so aufwändig zu implementieren. Allerdings wäre es insgesamt wohl am einfachsten und effektivsten wenn AVARDS die OSD-Settings ändert. Wer weiß wie schnell solche Dinge in andere Plugins einfließen wenn überhaupt .... und das bei der Anzahl an Plugins.

Wenn AVARDS das OSD nur dann skaliert und auch WSS nur dann schaltet wenn kein OSD offen ist, dann sollte der Zugriff auf die OSD-Einstellungen aus einem Thread heraus doch kein Problem darstellen oder? Das Schreiben und Lesen des Integer-Wertes ist ja atomar und sollte ja dadurch zu keinen Problemen führen .... aber ich kennen mich mit dem Threading nicht so gut aus und lasse mich da gerne belehren. Ansonsten müsste man ev. wirklich über den Main Thread gehen.
Vikings Vorschlag, dass AVARDS eigene OSD-Einstellungen hat (sowas wie max. OSD-Höhe und OSD-Breite von der aus nach unten skaliert wird) und dann nur diese berücksichtigt fände ich auch ideal. AVARDS sollte zwar dann beim Beenden wieder den Standard zurückschreiben, dass keine Einstellungen zurückbleiben wenn VDR ohne AVARDS startet, aber ansonsten sollte es dann bei Abstürzen zu keinen Problemen kommen.

Gruß,
Brougs78

Hallo Leute
ich bekomme beim make folgende Fehlermeldung :
g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"avards"' -I../../../include detector.c
detector.c: In member function `bool cWSSoverdrive::OpenVbiDevice(const char*)
':
detector.c:401: error: `V4L2_BUF_TYPE_SLICED_VBI_OUTPUT' undeclared (first use
this function)
detector.c:401: error: (Each undeclared identifier is reported only once for
each function it appears in.)
detector.c:402: error: 'union v4l2_format::<anonymous>' has no member named '
sliced'
detector.c:402: error: `V4L2_SLICED_WSS_625' undeclared (first use this
function)
detector.c: In member function `void cWSSoverdrive::SetWSS(int)':
detector.c:426: error: aggregate `v4l2_sliced_vbi_data data' has incomplete
type and cannot be defined

Was mache ich falsch ??
speed

Hi!

speed: Hast du ev. keinen aktuellen DVB-Treiber? Sieht so aus als ob dein Treiber das noch nicht kann.

Gruß,
Brougs78

Hy ich verwende den DVB Treiber
aus dem Kernel 2.6.21.1 ...
sollte doch gehen oder ??
speed

Hatte ich auch,

du musst die Kernel Header benutzen die habichthugo auf seiner Page bereitstellt.

Christian

gelöscht...

Danke
das wars ...
speed

Hallo FireFly!

Zitat

Original von FireFly

epg-edit

FireFly

Nein. Ich habe mir vorgenommen, dass ich mich mit VDRAdmin-AM wieder etwas beschäftige, wenn EnigmaNG v0.0.5 veröffentlicht ist. Zeitlich hoffe ich das das so in etwas zwei Wochen ist.

Gruß,
Andreas

Hi!

Zitat

Original von FireFly
Es kristallisieren sich also jetzt zwei Vorgehensweisen für die angepasste OSD-Größe heraus:

• Avards stellt eine Service-Schnittstelle zur Verfügung mit den zum aktuellen Zoom passenden Menügrößen.
  + ohne Änderungen am VDR-Setup möglich
  - nur Plugins die die Größe bei Avards abfragen profitieren davon
  

  
  

• Avards passt die Werte von Setup.OSDxyz an
  + alle Plugins arbeiten mit den angepassten Größen
  o Avards muss die Originalgröße beim Shutdown zurückschreiben sonst ist das OSD beim Start ohne Avards vollkommen falsch
  - es von einem Plugin in VDR-Setup geändert (evtl. nur im Main Thread möglich? siehe Post von triple955)
  - nach einen Crash startet VDR evtl. mit der falschen Größe

Was habe ich noch vergessen?

Mir persönlich sagt ja die Service-Variante eher zu, aber allen Plugins auf einen Schlag die richtige Größe zu verpassen hat auch was ....

FireFly

Alles anzeigen

Also ich würde die Service-Variante bevorzugen, obwohl - wie Du schreibst - Setup.OSDxyz-Variante natürlich Vorteile hat. Ich würde an Deiner Stelle mal Kontakt mit Klaus aufnehmen, was er davon hält, denn da könntest du auch abklären auf was Du beim Ändern der Werte beachten mußt.

Zitat

o Avards muss die Originalgröße beim Shutdown zurückschreiben sonst ist das OSD beim Start ohne Avards vollkommen falsch
- nach einen Crash startet VDR evtl. mit der falschen Größe

Ich denke nicht, dass Du das sauber hinbekommen kannst, da Du nicht mitbekommst, wann die Werte vom VDR/User geändert werden. Das Zurückschreiben der Werte beim VDR-Start bringt auch nicht unbedingt was, wenn Avards z.B. gar nicht geladen wird.

Aktiviert sollte es jedoch nicht per Default sein und die maximale Höhe sollte über das Setup einstellbar sein.

Gruß,
Andreas

Da bin ich wieder..
habe das Plugin jetzt mal ausprobiert !!
Großes Lob,funktioniert toll.
Vielen Dank
speed

Hallo,

Zitat

Original von speed
Hallo Leute
ich bekomme beim make folgende Fehlermeldung :
g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"avards"' -I../../../include detector.c
detector.c: In member function `bool cWSSoverdrive::OpenVbiDevice(const char*)
':
detector.c:401: error: `V4L2_BUF_TYPE_SLICED_VBI_OUTPUT' undeclared

Alles anzeigen

Nutze noch nicht das plugin da ich wss auch abshalten können möchte (wg. vdradmin) aber hier eine andere lösung die ich immer bei den avards programmen genutzt habe. Ich habe die sourcen der hg-DVB treiber dir ich nutze angegeben, dann hat es geklappt :

--- dvb-wss-overdrive.c.ORG    2006-03-28 22:48:18.000000000 +0200
+++ dvb-wss-overdrive.c 2006-03-30 08:11:13.884900000 +0200
@@ -28,7 +28,8 @@
 #include <sys/fcntl.h>
 #include <sys/ioctl.h>
 #include <linux/types.h>
-#include <linux/videodev2.h>
+// #include <linux/videodev2.h>
+#include "../DVB/include/linux/videodev2.h"
 #include <errno.h>
 #include <stdlib.h>

So was ähnliches müsste auch mit dem plugin gehen.

Gruß
Viking

Na, hat sich ja schliesslich doch noch jemand der Verpluggung angenommen - Super!

Möchtest du - FireFly - die AVARDS Hompage etc. auch mit übernehmen oder wie machen wir da weiter? Also soll ich mich von der Thematik verabschieden oder dir dabei unter die Arme greifen? Sach ma (vorzugsweise per Mail) an, was du dir vorstellst...

Zu der Thematik der Framebuffer-Nutzung, also parallelem Betrieb von avards, atmolight, Pictureshot-Funktion des VDR, Vorschaubild vdradmin etc. habe ich vor einiger Zeit schon mit kls per mail konferiert. Er hat die Realisierung einer Framebuffer-Sharing-Methode in Aussicht gestellt. Nachdem avards nun verpluggt ist müsste 'man' dazu halt noch mal freundlich bei kls nachfragen...

viking
Hy
also mal langsam zum mitschreiben für Dumme,in welcher Datei soll ich was
ändern ???
Habe das jetzt nich richtig verstanden ...
thank´s
speed