Dies ist eine Fortsetung von dieser Diskussion.
Vielleicht kann ja ein Mod den Rest verschieben.
Johns
Dies ist eine Fortsetung von dieser Diskussion.
Vielleicht kann ja ein Mod den Rest verschieben.
Johns
Moin,
Und nun zum Theme: Ausgabe Plugin vs. Ausgabe Client.
Beides hat seine Vorteile bzw Nachteile.
Ausgabe Plugin:
+ die Demuxer müssen nur einmal geschrieben werden
+ weniger Overhead (demux -> remux -> transport -> demux)
+ OSD braucht nicht übertragen werden, bzw doppelt programiert werden
- VDR ist nicht sehr schön bzw. gut bedienbar (persöhnliche Meinug)
- der Dekoder stützt bei defekten Streams häufiger ab
Ausgabe Client:
+ auf dem Client Rechner braucht nur der Client laufen Resource sparend auf dem Client.
+ Unterstützung von mehreren VDR Servern
+ Unterstütung von PIP
+ eigenes FULL-HD OSD möglich
Man könnte auch beides machen, der Ausgabe Teil kommt in eine eigene Library,
die von einem Client und einem Plugin verwendet werden. Dazu bräuchte man
einen Programmierer mehr.
So das ist erstmal alles was mir einfällt,
Johns
ZitatOriginal von johns
Ausgabe Plugin:
[...]
- VDR ist nicht sehr schön bzw. gut bedienbar (persöhnliche Meinug)
- der Dekoder stützt bei defekten Streams häufiger ab
True-Color-OSD kommt. Schon in der nächsten Entwickler-Version. Eben diese Abstürze galt es eigentlich irgendwie zu vermeiden. Wenn Grafikkarte aber nicht stabil zu bekommen ist, dann kann ich das Thema getrost wieder vergessen. Bleiben dann wohl doch nur Hardware-Decoder-Lösungen und da auch die eHD hier und da für Probleme sorgt bleibt wohl tatsächlich nur noch die kommende HD-FF.
Zitat
+ Unterstütung von PIP
OSDPIP-Plugin existiert und kann mit dem kommenden True-Color-OSD sicher noch optimiert werden.
Zitat
+ eigenes FULL-HD OSD möglich
Sorry, aber das OSD vom VDR ganz außen vor zu lassen ist IMHO total daneben. Dafür ist VDR zu mächtig, um ihn zum "Zuspieler" zu degradieren. Dann hat man dann letztlich wieder irgendein Aufsatz-OSD in dem keine Plugins bedient werden können und Schneiden der Aufnahmen nicht möglich ist.
Ähnliches ists mit XBMC bereits heute möglich und auch das ist meiner Meinung nach eine unschöne Lösung. Der VDR wird im Funktionsumfang ohne sein eigenes OSD, das auch von Plugins genutzt wird, einfach unnötig stark beschnitten.
Wie schon geschrieben: True-Color-OSD kommt. Passende Skins werden sicher folgen.
Bisher bin ich davon ausgegangen, dass es beim Thema "Client" darum geht, dass das VDR-eigene OSD an den Client mit übertragen wird. Wenn es aber nur ein zweites XBMC werden soll, dann kann ich nur eines dazu sagen: Schade.
+1 für Plugin
Vdr ist von der Basis her sowieso nicht als Backend oder Streaming Lösung gedacht. Ich denke, dass für alle, die den vdr "nur" als lokalen video disc recorder einsetzen, eine Pluginlösung ala Softdevice am einfachsten ist. Ich frage mich sowieso, wie viele vdr user wirklich eine client server Struktur haben. Ich weiß, dass viele, die hier im Forum aktiv sind, sowas haben, aber es gibt ja auch noch die passiven vdr nutzer. Ich würde annehmen, dass es dort weit weniger sind.
Aber vielleicht lässt sich ja, wenn erstmal ein plugin bzw. client für vaapi da ist, das jeweils fehlende ergänzen.
LG
Joachim
ZitatOriginal von gnapheus
Ich frage mich sowieso, wie viele vdr user wirklich eine client server Struktur haben. Ich weiß, dass viele, die hier im Forum aktiv sind, sowas haben, aber es gibt ja auch noch die passiven vdr nutzer. Ich würde annehmen, dass es dort weit weniger sind.
Die aktuell übliche VDR Client/Server Lösung basiert auf einer kleinen Auswahl an Plugins. Die Clients haben dann auch VDR laufen. Soweit ich weiß kann man dann vom Client aus entweder den Server aufnehmen lassen (Timer auf dem Server setzen) oder der Client nimmt auf. Alle Clients haben Zugriff auf die Server-Aufnahmen, ....
Gerade die mittlerweile sehr guten Möglichkeiten für Client-Server-Betrieb aus mehreren VDR-Installationen wurden in der Vergangenheit immer mal wieder als Vorteil von VDR genannt.
Wenn jemand lust auf kreative Theme-Entwicklung hat, dann sollte er das True-Color-OSD von kls abwarten um das Theme direkt für den VDR zu implementieren. Ein losgelöstes Frontend ist keine gute Lösung.
Hauptsache das ganze läuft stabil. Da vdr-sxfe noch immer ein paar Macken hat, bin ich ganz froh, dass es nicht den VDR mitreißt, wenn es mal abstürzt.
Ein Neustart des Clients/Frontends stört mich weniger als eine Aufnahme mit Unterbrechungen.
Die Möglichkeit den Client auf einem anderen Rechner laufen zu lassen halte für sehr praktisch, im Zweifelsfall nehme ich irgendeinen geigneten PC/Laptop und hänge ihn an das gewünschte Ausgabegerät - wobei der VDR mit all seinen TV-Karten und der nötigen Verkabelung bleiben kann, wo er ist.
ZitatOriginal von seahawk1986
Die Möglichkeit den Client auf einem anderen Rechner laufen zu lassen halte für sehr praktisch, im Zweifelsfall nehme ich irgendeinen geigneten PC/Laptop und hänge ihn an das gewünschte Ausgabegerät - wobei der VDR mit all seinen TV-Karten und der nötigen Verkabelung bleiben kann, wo er ist.
Geht auch mit der "klassischen" VDR Client/Server Lösung. Wobei es kaum Unterschied machen sollte, ob du ein HDMI-Kabel oder ein LAN-Kabel an den TV führst.
ZitatOriginal von Mreimer
Die aktuell übliche VDR Client/Server Lösung basiert auf einer kleinen Auswahl an Plugins. Die Clients haben dann auch VDR laufen. Soweit ich weiß kann man dann vom Client aus entweder den Server aufnehmen lassen (Timer auf dem Server setzen) oder der Client nimmt auf. Alle Clients haben Zugriff auf die Server-Aufnahmen, ....
Gerade die mittlerweile sehr guten Möglichkeiten für Client-Server-Betrieb aus mehreren VDR-Installationen wurden in der Vergangenheit immer mal wieder als Vorteil von VDR genannt.
Dessen bin ich sehr wohl bewusst. Das ändert aber nichts daran, dass vdr laut kls nicht dafür konzipiert wurde.
LG
Joachim
Stimmt. Ist eine Lösung der Community. Habe ich selber auch nicht in Betrieb. Bei mir ist der VDR auch eine "Stand-Alone-Kiste" mit eigenen Aufnahmen, eigenen Tunern und eigener Ausgabe.
Hi,
will auch mal meinen Senf dazugeben.
Ich nutze seit einigen Jahren gezwungenermaßen eine Client-Server Lösung. (Ich habe an der Stelle wo der TV steht keine SAT-Anschlüsse.)
Ich hab in der Zeit die beiden möglichen Varianten ausprobiert und finde die Variante wie es vdr-sxfe aktuell macht am besten.
Hier wird der Client wie ein verlängerter Arm vom VDR benutzt. Soll heißen ich steuere den VDR auf dem Server direkt. Das hat nach meiner Meinung einige Vorteile:
-- kurze Zeiten beim Umschalten
-- reine Ausgabe am Client ohne VDR installiert zu haben (diskless Client)
-- volle VDR Funktionalität (schneiden, OSD, Plugins, ...)
-- Umschaltung auf z.B. XBMC
-- überall einsetzbar wo es Netzwerk gibt
-- kein NFS Gedöns
-- Aufnahmen sofort verfügbar
Jetzt noch was mir bei der streamdev Lösung nicht gefällt:
-- Umschaltzeiten zu lang
-- Channel.conf gleich halten
-- nicht alle Plugins verwendbar (epgsearch)
-- EPG Synchronisation
-- schneiden von Aufnahmen übers Netzwerk
-- Funktionen vom OSD Skins nicht alle vorhanden (Timeranzeige, Femon, ...)
Mir währe damit eine Lösung wo ein Plugin den Stream bereitstellt (Netzwerk, Pipe für lokal) und einen Programm für die Bildausgabe das auf dem Client oder direkt auf dem VDR läuft am liebsten.
Sozusagen vdr-sxfe ohne xine.
Wobei ich auch sagen muss, das es nicht schlecht ist beide Arten zu haben. vdr-sxfe mit vaapi als Backend (siehe epsi) und ein reines vaapi Ausgabedevice. Ist nur die Frage was können die vaapi Backens. Ich denke da an Autocrop, Scaling für pixelgenaue Ausgabe, ...
Mein Fazit ist, je nachdem was vaapi kann wird beides gebraucht und mit xineliboutput ist schon eine Lösung da die erweitert werden muss um vaapi voll zu unterstützen.
Gruß Lokutus
ZitatOriginal von lokutus
Mein Fazit ist, je nachdem was vaapi kann wird beides gebraucht und mit xineliboutput ist schon eine Lösung da die erweitert werden muss um vaapi voll zu unterstützen.
Eben deshalb war ich eigentlich der Meinung, dass es die Lösung mit abgesetzter Ausgabe bereits gibt.
Für mehrere Clients kommt man um die Streamdev-Lösung ohnehin nicht herum. Wenn diese langsam ist, sollte man an dieser Stelle optimieren.
Was noch komplett fehlt ist eine direkte Ausgabe ähnlich softdevice, die ohne enorme CPU-Last auch mit HD kann.
ZitatOriginal von Mreimer
Eben deshalb war ich eigentlich der Meinung, dass es die Lösung mit abgesetzter Ausgabe bereits gibt.
Warum wehrt du dich denn so vehement dagegen, dass die Anhänger einer abgesetzten Lösung ebenfalls von einer Anwendung profitieren können, die ohne den Umweg über die xine-lib arbeitet?
Gerald
ZitatOriginal von gda
Warum wehrt du dich denn so vehement dagegen, dass die Anhänger einer abgesetzten Lösung ebenfalls von einer Anwendung profitieren können, die ohne den Umweg über die xine-lib arbeitet?
Ich gebe zu, dass ich schon lange darauf warte, dass der VDR mit direktem Ausgabe-Plugin auf *kürzestem Weg* auf die Grafikkarte ausgeben kann.
Mir gefällt der VDR so wie er ist inklusive OSD und Plugins. Zumal ja True-Color-OSD kommen wird.
Als Va-api jetzt wieder aufgekommen ist, hatte ich wieder Hoffnung, dass das Va-api-Softdevice-Plugin endlich realistisch wird.
Allerdings habe ich meine Wünsche jetzt wohl recht ausführlich dargelegt und ziehe mich demnach jetzt aus dem Thread zurück.
Letztlich muss derjenige, der das ganze letztlich programmiert, entscheiden, was er tun will und ich muss das Resultat ja nicht nutzen.
ZitatOriginal von Mreimer
Allerdings habe ich meine Wünsche jetzt wohl recht ausführlich dargelegt und ziehe mich demnach jetzt aus dem Thread zurück.
Letztlich muss derjenige, der das ganze letztlich programmiert, entscheiden, was er tun will und ich muss das Resultat ja nicht nutzen.
Bitte nicht, wenn es noch Sachliche Gründe gibt, bitte weiter schreiben.
Stimmt, im Endeffekt muss es jemand schreiben. Sieh den Thread auch als Anregung an jemanden
dies zutun.
Nachteil plugin: VDR vs X11
Man kann VDR auch starten bevor das X11 gestartet wird.
Das Plugin kann entweder X11 selber starten oder auf X11 warten.
Ist somit kein Nachteil, muss nur berücksichtigt werden.
Johns
ZitatOriginal von johns
Nachteil plugin: VDR vs X11
Man kann VDR auch starten bevor das X11 gestartet wird.
Das Plugin kann entweder X11 selber starten oder auf X11 warten.
Ist somit kein Nachteil, muss nur berücksichtigt werden.
So geschehen bei Ausgabe über das softdevice-Plugin, was beweist das es funktioniert und kein Nachteil ist.
Auch mir wäre ein "integriertes" Ausgabe-Plugin lieber und hoffe das das dabei rauskommt. Ich glaube nämlich auch das die bereits bestehenden xine-Ausgabelösungen von diesen VAAPI Arbeiten mittelbar profitieren und damit wäre am Ende für jeden etwas dabei.
Regards
fnu
Hallo,
mir persöhnlich wäre ein plugin lieber. Das gilt aber nur wenn sich die Umschaltzeiten bei einer anderen Lösung nicht extrem erhöhen.
Gruß
Atech
ZitatAuch mir wäre ein "integriertes" Ausgabe-Plugin lieber und hoffe das das dabei rauskommt.
Dem schliess ich mich an da meine Vdrs hier auch ausschliesslich als Stand Alone Kisten
laufen.
Gruss
Bert
Moin
Freiwillige vor, wer kann C++ und schreibt ein HDTV Software Decoder Plugin?
Mit dem Decoder und Video/Audio Setup könnte ich helfen.
Wenn ich es richtig sehe, kann man keine reinen C Plugins schreiben?
Das softdevice Plugin kann als Beispiel dienen, ist aber viel zu kompliziert.
cDevice : : PlayVideo spielt ein PES Packet ab, das wird an avcodec_decode_video2 übergeben.
Jetzt müsste man noch herausfinden ob es ein MPEG2 oder H264 Stream ist.
Johns
Hi
Ich möchte eine kurze Frage in die runde werfen . Und zwar ist es nicht möglich eine art hybrid zu bauen? Ein Plugin was Standalone funtkioniert und gegebenfalls die Daten an einen Client weiterreichen kann.
mfg
ZitatOriginal von avjui
Hi
Ich möchte eine kurze Frage in die runde werfen . Und zwar ist es nicht möglich eine art hybrid zu bauen? Ein Plugin was Standalone funtkioniert und gegebenfalls die Daten an einen Client weiterreichen kann.
Sicher ist das möglich, so funktioniert xineliboutput.
Gerald
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!