[3dcontrol] Plugin zur Steuerung der 3D Funktionen von Ausgabe Pugins und 3D TV's

  • So hier das erste Ergebnis aus diversen Threads und meinen ersten C++ Erfahrungen.


    UPDATE: 08.11.2012 - hier gibts Version 0.0.2
    UPDATE: 19.11.2012 - hier gibts Version 0.0.3



    Ansonsten viel Spass bei der Fehlersuche :D


    UPDATE: 08.11.2012 - hier gibts Version 0.0.2
    UPDATE: 19.11.2012 - hier gibts Version 0.0.3

  • Danke für das veröffenltichen, bin da schon gespannt drauf seit ich in den anderen Threads von gelesen habe. Ihc werde es heute Abend oder morgen mal testen.


    Für die Steuerung des LG über Netzwerk habe ich vor ein paar Tagen schonmal das Pairing Quick&Dirty in C++ geschrieben. Funktioniert soweit auch und FB Befehle kann ich problemlos senden. Weiteres geht leider noch nicht, über UDP kann man Commands senden die zumindest der RS232 Kommunikation sehr ähnlich sehen, ob es aber klappt hier diese Commands auch abzusetzen muss ich noch testen (bzw. das UDP Geraffel überhaupt erstmal bauen).


    Zu dem bisherigen Umfang hätte ich, basierend auf dem Announce, weitere Vorschläge:
    Die Vorschläge bitte nicht negativ auffassen, sondern als Hinweise das ganze weiter zu verbessern.


    - Die Module für die TV Steuerung nicht übers Makefile, sondern evtl. als eigenes Plugin-System. Auf jedenfall alle Module kompilieren und die Nutzung übers OSD einstellbar machen. Sonst wirds unmöglich das Plugin diversen Distris beizulegen.
    - Erkennung ob der Sender 3D nutzt über den Namen finde ich als erste Lösung nicht schlecht. Hier sollte aber zusätzlich die Möglichkeit dazukommen, das für bestimmte Sender festlegen zu können. Ich könnte mir das Handling analog zur Zuweisung der Quellen im xmltv2vdr-Plugin vorstellen
    - Für Mediaplayer und Ausgabe-Plugin könnte das Plugin zukünftig eine Service-Schnittstelle bieten um, falls zukünfrtig vorhanden, eine fest definierte Schnittstelle zu bieten, die andere Plugins nutzen können. Vorteil ist andere Plugin-Entwickler könnten den Service dieses Plugins nutzen um das OSD umzuschalten und müssten nicht jeweils eigenen Code für diverse Ausgabe-Plugins pflegen
    - Erweiterte Steuerung der TV-Geräte würde ich in ein extra Plugin auslagern. Solche Sachen wie einschalten, Lautstärke, ... haben ja nicht wirklich was mit 3D zu tun
    - Erkennung welches 3D Format vorliegt halte ich für ein sehr gutes Feature, befürchte allerdings das dies einiges an Leistung kosten könnte

  • Code
    [...]
       Die 3D Erkennung beschränkt sich auf die Überprüfung des Sender- bzw. Dateinamens 
       (dazu zählt auch der Pfad), ob "3D" vorkommt. ...


    Wird aber bei folgenden Sendern schwierig werden:


    da diese nicht in 3D senden. ;)

  • Die Vorschläge bitte nicht negativ auffassen, sondern als Hinweise das ganze weiter zu verbessern.

    So hab ichs mir gedacht.



    - Die Module für die TV Steuerung nicht übers Makefile, sondern evtl. als eigenes Plugin-System. Auf jedenfall alle Module kompilieren und die Nutzung übers OSD einstellbar machen. Sonst wirds unmöglich das Plugin diversen Distris beizulegen.

    So hatte ich es schon geplant, entweder separate SubPlugins oder Konfigurierbar per OSD



    - Erkennung ob der Sender 3D nutzt über den Namen finde ich als erste Lösung nicht schlecht. Hier sollte aber zusätzlich die Möglichkeit dazukommen, das für bestimmte Sender festlegen zu können. Ich könnte mir das Handling analog zur Zuweisung der Quellen im xmltv2vdr-Plugin vorstellen

    Den Vorschlag von Dir hatte ich schon aus dem anderen Thread auf meine Liste übernommen.



    - Für Mediaplayer und Ausgabe-Plugin könnte das Plugin zukünftig eine Service-Schnittstelle bieten um, falls zukünftig vorhanden, eine fest definierte Schnittstelle zu bieten, die andere Plugins nutzen können. Vorteil ist andere Plugin-Entwickler könnten den Service dieses Plugins nutzen um das OSD umzuschalten und müssten nicht jeweils eigenen Code für diverse Ausgabe-Plugins pflegen

    mal schauen, eine Serviceschnitstelle für andere Plugin kommt aber auch noch



    - Erweiterte Steuerung der TV-Geräte würde ich in ein extra Plugin auslagern. Solche Sachen wie einschalten, Lautstärke, ... haben ja nicht wirklich was mit 3D zu tun

    So hab ich es hier ja schon, ich hatte nur die Funktion LG TV schon als extra Modul eingebaut, solange das andere Plugin noch so eine große Baustelle ist.



    - Erkennung welches 3D Format vorliegt halte ich für ein sehr gutes Feature, befürchte allerdings das dies einiges an Leistung kosten könnte

    mal schauen :D

  • TODO
    - Erweiterung der Steuerungsmöglichkeiten für TV Geräte (ein/aus schalten, Lautstärke usw.)
    - ......


    Das sollte man auch noch nicht vorhandenem Plugin überlassen


    [Pluginwunsch bzw. Featurewunsch] CEC Unterstützung für VDR


    ansonsten super Idee

  • Ich habe mal mit der Kommunikation über Netzwerk zum LG etwas weiter getestet. Die Befehle für RS232 über UDP funktioniert anscheinend so nicht, zumindest reagiert der TV nicht. Über TCP lassen sich Tastendrücke der Fernbedinung senden. Wertebereich ist 0-255. Ich habe mir die Liste aus lgremote vorgenommen und die Lücken darin ausgetestet. Auf den meisten erfolgt keine Reaktion, ein paar dort nicht dokumentiere konnte ich finden. Es war leider nichts dabei um den 3D-Modus direkt zu schalten. Einzige Möglichkeit wäre 3D, Ok, Ok. Dann wird allerdings immer die zuletzt ausgewählte 3D Art genutzt, also nicht wirklich brauchbar um das in ein Plugin zu packen.

  • Das Plugin lässt sich bei leider nicht bauen. :(


    Der Compiler bricht mit folgendem Fehler ab:


    Code
    vdr01 3dcontrol-0.0.1 # make clean all
    g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -march=native -D__STDC_CONSTANT_MACROS -fPIC -ggdb -O0 -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_ALTERNATECHANNEL -DUSE_CHANNELBIND -DUSE_CUTTERLIMIT -DUSE_DDEPGENTRY -DUSE_DVLVIDPREFER -DUSE_GRAPHTFT -DUSE_HARDLINKCUTTER -DUSE_JUMPINGSECONDS -DUSE_JUMPPLAY -DUSE_LIRCSETTINGS -DUSE_LIEMIKUUTIO -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NALUDUMP -DUSE_PINPLUGIN -DUSE_PLUGINMISSING -DUSE_ROTOR -DUSE_TIMERINFO -DUSE_TTXTSUBS -DUSE_VOLCTRL -DUSE_WAREAGLEICON -DUSE_YAEPG -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"3dcontrol"' -I/usr/local/src/VDR/include -I-I./include -I./include control.c
    g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -march=native -D__STDC_CONSTANT_MACROS -fPIC -ggdb -O0 -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_ALTERNATECHANNEL -DUSE_CHANNELBIND -DUSE_CUTTERLIMIT -DUSE_DDEPGENTRY -DUSE_DVLVIDPREFER -DUSE_GRAPHTFT -DUSE_HARDLINKCUTTER -DUSE_JUMPINGSECONDS -DUSE_JUMPPLAY -DUSE_LIRCSETTINGS -DUSE_LIEMIKUUTIO -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NALUDUMP -DUSE_PINPLUGIN -DUSE_PLUGINMISSING -DUSE_ROTOR -DUSE_TIMERINFO -DUSE_TTXTSUBS -DUSE_VOLCTRL -DUSE_WAREAGLEICON -DUSE_YAEPG -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"3dcontrol"' -I/usr/local/src/VDR/include -I-I./include -I./include 3dcontrol.c
    3dcontrol.c: In member function âchar* cMyStatusMonitor::stristr(const char*, const char*)â:
    3dcontrol.c:33:41: error: âtoupperâ was not declared in this scope
    3dcontrol.c:39:31: error: âtoupperâ was not declared in this scope
    make: *** [3dcontrol.o] Error 1
    vdr01 3dcontrol-0.0.1 #
  • Das scheint aber mit dem OSD nicht ganz zu passen. Auf C-3POs Screenshot, sowie in meinem Test gerade hängt das rechte Osd mit ins linke Bild rein.


    bei mir liegen die beiden OSD's direkt übereinander, ich denke weil ich einen anderen Skin benutze und folgende OSD Einstellungen:

    Code
    OSDHeightP = 1.000000
    OSDLeft = 0
    OSDLeftP = 0.000000
    OSDTop = 0
    OSDTopP = 0.000000
    OSDWidthP = 1.000000

    damit passts.


    Da ich in dem Patch für Softhddevice nicht berücksichtigt habe, das man das OSD ja innerhalb des Bildschirms verschieben kann.


    Werd ich mir nochmal anschauen und versuchen den Patch anzupassen.

Jetzt mitmachen!

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