Posts by Nano

    Hallo zusammen.


    Ich habe etwas Zeit gefunden und das Tool "netcv2dvbip" etwas überarbeitet. Die Änderungen sind auch schon im SVN bei Baycom.


    Ich habe die Änderung nochmal nachvollzogen. Die Umstellung von VDR-1.7.12 -> VDR-1.7.13 hinsichtlich der Behandlung möglicher "Sources" wurde überarbeitet. Ein Plugin kann jetzt nämlich eine eigene "Source" definieren und in VDR bekannt machen. Zum Beispiel statt DVB-C/-T/-S auch IPTV als Quelle.


    Ich habe daher den Patch noch um ein #ifdef VDRVERSUM erweitert.

    Sorry. Hab' gerade erst gesehen, dass kris diesen Patch hier veröffentlich hat:



    Damit funzt es jetzt wieder. :)


    Hi,


    bei mir rennt 1.7.14 auch nicht. Ich habe es auf dem Netclient getestet. Dort lief zuletzt der VDR-1.7.10 ohne Probleme. Habe ich vielleicht doch etwas beim Patchen falsch gemacht? Vielleicht sollten wir da nochmal drüber schauen. Die Änderung an der Basisklasse war ja nicht wirklich wild.
    Aber vielleicht war es doch zu quick'n' dirty. ;)


    Mir war aber so, als hätte ich den 1.7.14 mit dem gepatchten mcli-PI ohne Probleme damals laufen gehabt (direkt nach Erstellung des Patch).


    Kann es evtl. sein, dass Baycom was am PI rumgeschraubt hat, weswegen der Patch jetzt nicht mehr funzt?! Der Patch wird zwar sauber angewendet, aber ob das reicht?


    Da ist wohl eine nähere Untersuchung fällig.



    Hi,


    leider nur tvheadend-pvrclient.

    Quote

    Originally posted by TheChief
    Also unter OSX muss ich ein "make libaddon" machen, damit die Libs gebaut werden. Probier das doch mal, falls das überhaupt unter Windows geht.


    Grüsse
    TheChief


    Hi!


    Ich habe es jetzt hinbekommen mit dem tvheadend-pvrclient für XBMC.
    Die Makefiles sind wirklich nur für Linux/OSX.


    Ich habe mir jetzt an Anlehung an vdr-streamdev-pvrclient ein VS2008 Projekt zusammengebaut mit dem es sich für Windows übersetzen läßt.


    Habe jetzt alles zusammen am Laufen.


    Netceiver->tvheadend mit mcli/dvbloop auf Sheevaplug->XBMC-pvr-testing2 auf meinem Windows XP Desktop mit dem tvheadend-pvrclient für XBMC.

    Hallo,


    ich habe den aktuellen pvr-testing2-Snapshot von heute soweit laufen.


    Kann mir jemand einen Tipp geben, wie man die pvrclient-AddOns von XBMC für Windows baut?


    Diese AddOns sind ja leider nicht in den Visual Studio Projekt-Files enthalten.
    Das Makefile scheint auf Linux/MacOS ausgelegt zu sein.


    Mich interessieren vor allem die AddOns für tvheadend und vdr-vnsi.


    Danke und Gruß
    Nano


    Ok. Ich habe es selbst gefunden.
    Die Datei "AddonHelpers_GUI.cpp" fehlt im Projekt"XBMC" unter Visual C++ 2008. Jetzt wird sie auch kompiliert und XBMC startet.


    Jetzt habe ich schon das nächste Problem:
    Ist der VNSI PVRClient Source Code derzeit überhaupt für Windows zu gebrauchen?
    Ich habe kein VS Projekt-File gefunden. Daraufhin habe ich es selbst zusammen gebaut. Aber dann werden eine Menge Dinge eingebunden, die es nur unter Linux gibt.


    Wie bauche ich das VNSI PVR Client Plugin für XBMC?

    Tach,


    bin jetzt erst auf diese ganze XBMC Geschichte aufmerksam geworden.
    Die normale Version aus dem SVN kann ich ohne Probleme erzeugen und starten.


    Leider habe ich mit dem aktuellen pvr-testing2 Zweig ein Problem.
    Hat irgendjemand spontan eine Lösung dafür?


    Code
    1. 1>ApplicationMessenger.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""public: void __thiscall ADDON::CGUIAddonWindowDialog::Show_Internal(bool)" (?Show_Internal@CGUIAddonWindowDialog@ADDON@@QAEX_N@Z)" in Funktion ""private: void __thiscall CApplicationMessenger::ProcessMessage(struct ThreadMessage *)" (?ProcessMessage@CApplicationMessenger@@AAEXPAUThreadMessage@@@Z)".
    2. 1>AddonHelpers_local.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""public: __thiscall ADDON::CAddonHelpers_GUI::~CAddonHelpers_GUI(void)" (??1CAddonHelpers_GUI@ADDON@@QAE@XZ)" in Funktion ""public: void * __thiscall ADDON::CAddonHelpers_GUI::`scalar deleting destructor'(unsigned int)" (??_GCAddonHelpers_GUI@ADDON@@QAEPAXI@Z)".
    3. 1>AddonHelpers_local.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""public: __thiscall ADDON::CAddonHelpers_GUI::CAddonHelpers_GUI(class ADDON::CAddon *)" (??0CAddonHelpers_GUI@ADDON@@QAE@PAVCAddon@1@@Z)" in Funktion ""public: static struct CB_GUILib * __cdecl ADDON::CAddonHelpers::GUILib_RegisterMe(void *)" (?GUILib_RegisterMe@CAddonHelpers@ADDON@@SAPAUCB_GUILib@@PAX@Z)".
    4. 1>XBMC\Debug (DirectX)\XBMC.exe : fatal error LNK1120: 3 nicht aufgelöste externe Verweise.
    5. 1>Das Buildprotokoll wurde unter "file://d:\pvr-testing2\project\VS2008Express\XBMC\Debug (DirectX)\BuildLog.htm" gespeichert.
    6. 1>XBMC - 4 Fehler, 2 Warnung(en)
    7. ========== Erstellen: 0 erfolgreich, Fehler bei 1, 53 aktuell, 0 übersprungen ==========


    Hi,


    also ich habe hier den VDR mit den Diff's von kls von 1.7.12 auf 1.7.14 aktualisiert. Das mcli-PI habe ich frisch ausgecheckt. Das Problem liegt in device.c. Die Klasse cChannel enthält die Member System(), Modulation(), Inversion(), etc. nicht mehr. Stattdessen muss man sich einen String holen und den Parsen, damit man wieder an die Parameter kommt. Das Parsen macht die neue Klasse cDvbTransponderParameters.

    Hi,


    sorry. Ich muss diesen alten Eintrag nochmal hochholen, weil ich ihn gerade erst gesehen habe.


    Quote

    Originally posted by Razorblade
    Zu Variante 1 kann ich nicht viel sagen, mir ist mein Netceiver leider "um die Ohren geflogen" bevor ich das Testen konnte. Ich weiß auch gar nicht genau, ob das überhaupt unter Windows lauffähig ist?!? Von den 3 Varianten aber sich noch die Erfolgsversprechendste


    DVBLink würde ich nicht empfehlen, die benötigte Rechenleistung ist hoch, die Qualität des Bildes schlecht und der Stream sehr instabil. Ich habe das vor kurzem gerade mit DVBLink for IPTV und vdr-streamdev getestet. Der pure stream vom Streamdev ist ok, aber durch die virtuellen DVBLink Devices kommt nur sehr schlechte Qualität und bei 720p gar nichts (Öffentlich Rechtliches HD!)


    Ursprünglich war diese Variante 1 für mich überhaupt der Anlass, netcv2dvbip zusammen zu bauen. netcv2dvbip sollte unter Windows laufen. Allerdings habe ich es nur mit Windows XP, dem MS Loopbackadapter und VLC getestet. Das funktionierte. Mangels Windows Vista/7 konnte ich DVBLink nicht testen.


    Razorblade :
    Was mich interessiert: Dieses DVBLink für IPTV generiert doch erstmal nur
    eine virtuelle DVB-karte unter Windows. Das hat doch dann aber erstmal gar nichts mit der Dekodierung zu tun oder verstehe ich da etwas falsch?
    Dieses DVBLink stellt doch im Sinne des Directshow Filtergraphen nur eine Quelle zur Verfügung.


    Welchen Codecs hast Du denn zur Dekodierung von MPEG-2 und H.264 Material getestet, dass die Bildquali so schlecht war?


    Gruß
    Nano

    Ich habe für den Reelvdr ein Plugin geschrieben, das ffplayer heißt.
    Dieses benutzt ffmpeg, um verschiedene Container-Formate lesen zu können und dann an den Reelvdr auf dem Netclient weiterzugeben.


    Der Hardware-Decoder unterstützt in der Tat "nur" MPEG2 und H264 für Video und für Audio ist derzeit nur MPEG-layer2 und AC3 im Treiber implementiert. Die Hardware kann aber auch AAC, EAC3 und DTS. Das muss aber erst noch getestet werden und in den Treiber eingebaut werden.


    Momentan benutzte ich hauptsächlich MKV Dateien, die MPEG2 oder H264 mit AC3 enthalten. Diese Dateien kann man ganz einfach und prima mit MakeMKV aus einer DVD oder Bluray erzeugen.


    Ich werde eine erste Beta-Version des ffplayer-Plugins für den Netclient in den nächsten Tagen veröffentlichen.


    Übrigens: ein Echtzeitumwandeln von XVid oder Divx in MPEG2 oder so kann man vergessen. Dafür ist die normale ARM-CPU viel zu schwach.


    Noch was: wer möchte, kann ja auch den normalen VDR-1.7.13 auf dem Netclient laufen lasesen. Ich habe dafür das Ausgabe-Plugin (rbmini) ein wenig angepasst. Die IR-Fernbedienung ist auch ganz normal über das remote-PI nutzbar.

    Das Ziel war ja hauptsächlich das Ausgabe-Plugin für den vdr-1.7.x fit zu machen. Mit 1.7.12 wurden noch ein paar Änderungen gemacht, die ich noch nicht wieder angepasst habe. Daher ist das Ausgabe-Plugin derzeit nur bis 1.7.11 lauffähig.


    Man kann also jetzt auf seinem Netclient sein komplett eigenes Image mit einem "normalen" VDR laufen lassen. Das streamdev-Plugin sollte also auch ohne Probleme laufen, wenn es mit dem vdr-1.7.11 läuft.


    Momentan beschäftige ich mich aber mit diesem Thema nicht, da ich ein videoplayer-Plugin für den Reelvdr schreibe.