Reines Ausgabeplugin für libva mit dem VDR?

Copperhead

Nvidia hat in letzter Zeit sicher nicht durch tolle Geschäftszahlen geglänzt, hat keinen strategischen Partner und ausser den stromfressenden Fermis keine wirklich neuen Produkte lanciert, noch nicht mal durch Gerüchte. Und mit den paar Hanseln die VDPAU am HTPC nutzen, fütterst Du keine Firma ...

wbreu

Hab schon gesagt, trage mein Schärflein, was auch immer sinnvoll ist und benötigt wird, HW Spenden etc. Aber Code-Zeilen geht gar nicht ...

Gruß
Frank

die RX1550 basiert auf dem R5x0 Chip und der liefert keine HD-Videobeschleunigung
keine Ahnung warum das auf dem Karton steht

Meep. Wieder mal am Codecs verwechseln. Von H264 stand dort nirgends das die Karte das unterstützen würde, lediglich mpeg4 maximimal. Mpeg4 ist mehr sowas Richtung Divx, wobei die Karte eben Teile des Decodingprozesses übernehmen kann. Um Xvba auszuprobieren braucht man mindestens eine Radeon HD2400, maximal eine aus der HD4000er Serie, die neueren Evergreen Chips funktionieren nicht. Auch unter den Karten zwischen 2400 und 4970 gibt es aber einige Kandidaten die keinen Support haben, darum ein wenig aufpassen.

Das Xbmc mit VAAPI auf Ati kein OSD auf den Schirm kriegt liegt an der Art wie Xbmc es erzeugt, heraus aus einem OpenGL Kontext per VaPutSurface(), das geht derzeit nicht mangels Unterstützung im Treiber.

Ich persönlich fände es schade wenn man versuchen würde das was eine FF Karte ausmacht auf ein neues System auszurollen, weil man sich damit auch wieder die vielen Limitationen ins Haus holt die so eine FF nunmal hat, am krassesten die eingeschränkte Verwendbarkeit. Das Client/Server Modell hat eben die geniale Möglichkeit nicht immer zum Server connected sein zu müssen und auch mal was anderes auf die Glotze zu kriegen, und da bieten neue Geräte einen Riesenspielplatz.

Ich glaub ich setz mich nachher mal hin und formulier mal in einen Thread meine Visionen wovon ich immer träume das man das mal aus dem vdr macht. Mal sehen was ihr anderen dazu sagt

Ich würde es eher bevorzugen die Sache in ein Plugin und einen Player zu zu splitten.

Man währe wie schon erwähnt deutlich flexibler:

• Parallelbetrieb anderer Programme.
• Räumliche Trennung von Aufnahme- und Wiedergabe-Rechner (Für Computergamer letzterer evtl. sogar als dualboot mit anderem OS).
  Die Hardware-Anforderungen an den Aufnahmerechner sind dann nur minimal und der Widergaberechner kann sehr schön kompakt werden, da dort keine DVB-Karten eingebaut werden müssen.

Neben der schon erwähnten höheren Flexibelität sehe ich noch weitere Vorteile:

• Das Plugin braucht die Daten nur weiter zu leiten, wird also sehr kompakt und übersichtlich (und dadurch hoffentlich auch sehr stabil).
• Wenn man die Schnittstelle gut durchdacht ist, hat ein Absturz des Players keine Auswirkung auf die Funktion des VDR.
  Es ist dann nur ein Neustart des Players erforderlich, Aufnahmen laufen dabei aber ungestört weiter (so ist das beim ARM auf der FF übrigens auch gelöst).
• Wenn die Schnittstelle sauber definiert wird erleichtert das die Arbeitsteilung (je ein Team für Player und Plugin).
• Der Player braucht nur zu laufen, wenn auch ferngesehen wird.
  Das spart Strom und ein Programm was nicht läuft belastet das System nicht und kann auch keine Fehler verursachen.

Zitat

Original von SHF
Ich würde es eher bevorzugen die Sache in ein Plugin und einen Player zu zu splitten

Dann braeuchte man wohl kein Plugin mehr, denn es gibt ja bereits vnsiserver, xine, xineliboutput, streamdev ...
Rein aus Performancegruenden waere aber ein direktes Ausgabeplugin hilfreich ...

Zitat

Original von Hibbelharry
Ich persönlich fände es schade wenn man versuchen würde das was eine FF Karte ausmacht auf ein neues System auszurollen, weil man sich damit auch wieder die vielen Limitationen ins Haus holt die so eine FF nunmal hat, am krassesten die eingeschränkte Verwendbarkeit.

Was meinst du mit "eingeschränkter Verwendbarkeit"?

Zitat

Das Client/Server Modell hat eben die geniale Möglichkeit nicht immer zum Server connected sein zu müssen und auch mal was anderes auf die Glotze zu kriegen, und da bieten neue Geräte einen Riesenspielplatz.

Wenn ich "was anderes auf die Glotze" will, dann will ich das vom VDR-OSD aus tun. Die Zukunft vom VDR liegt sicher nicht darin, die VDR-Software als Medienzentrale zu vernachlässigen und alles, was nicht mit TV zu tun hat, mit externen Programmen zu machen.

Durch die eingeschränkte Verfügbarkeit von Media-Player-Software, die direkt aus dem VDR raus läuft (MPlayer-Plugin ist ein *sehr* guter Start, aber sicher noch ausbaufähig) hat es sich zur Normalität entwickelt, zwischen verschiedenen Programmen zu wechseln. Beim Browser sehe ich das ein, aber für die pure Mediennutzung wäre eher das System der Avantgarde anzustreben. Alles über ein Menü, alles mit einem einheitlichen Theme. Kein Wechsel zwischen grundverschiedenen Programmen.

Der stabilste Weg, um den VDR erstmal an die Grafikhardware zu bekommen, ist sicher ein direktes Ausgabeplugin, welches die Daten vom VDR ohne Umwege in die VAAPI stopft. Alles weitere kann später diskutiert werden.

Zitat

Original von SHF
* Der Player braucht nur zu laufen, wenn auch ferngesehen wird.
Das spart Strom und ein Programm was nicht läuft belastet das System nicht und kann auch keine Fehler verursachen.

Das gilt nur für diejenigen, die ohnehin einen VDR-Server betreiben. Wer das weder braucht, noch will, spart garnichts, da der VDR an sich nur dann läuft, wenn ferngesehen und/oder aufgenommen wird. Zudem gibt es für den VDR mit dem Streamdev-Plugin schon eine ausgefeilte Client-Server-Lösung. Warum dann gerade an der Stelle VDR-Software -> Grafikausgabe nochmal eine IP-Schicht dazwischen muss, erschließt sich mir nicht.

Zitat

Original von wbreu
- tbshl-vdr, schreib doch mal bitte ein paar Worte was du schon gesichtet hast / angefangen hast? => eventuell kann ja aelo dann mit einsteigen....

(Wollte aelo nicht erstmal studieren )
Naja, so viel ist das auch noch nicht, und vor nächster Woche wird mangels Zeit auch nicht mehr viel passieren. Hab mich erstmal an xbmc orientiert, welches ffmpeg benutzt.
Was mir da auffiel: das hat die ffmpeg-Quellen mit drin (und einigen anderen libs). Das mag ja Vorteile haben - kein Ärger wg. untwerschiedlicher Versionen beim Benutzer z.B., aber irgendwie ist das doch nicht ganz der Sinn dessen...

Ein eigenständiges Plugin: Wirklich dafür bin ich nicht. Wird darin dann wirklich gar nix anderes genutzt, oder z.B. ffmpeg? Wenn erstmal nur für DVB mag der Aufwand geringer sein - Decoder für mpeg/h264, aber wenn dann noch Medien dazukommen sollen... Und Audio nicht zu vergessen.

Vorteil: man kann die Fehler der anderen Implementationen weglassen. Und viele neue einbauen

Gruss,
Thomas

Zitat

Original von wbreu
der Grundgedanke ist halt erstmal die libva hinsichtlich VDR inkl. OSD zum Laufen zu bekommen, das möglichst mit Blick auf einfache Konfiguration und absolute Stabilität verbunden mit "kein unnötiger Ballast = Fehleranfälligkeit".

Ja schon, aber um libva zu nutzen sind ja noch die Decoder notwendig, und das ist ja nicht ganz ohne, besonders bei h264. Die sind ja vorhanden - xine-lib oder z.B. ffmpeg. Auf irgendetwas sollte das schon aufbauen, entweder als lib, oder übernommener Code, oder auch erweiterte xine-lib, oder...
Und auch nicht zu vergessen Audio und AV-Synchronisation.

Zitat

Original von wbreu
Wenn ich mir die xine-lib-1.2-Entwicklung so ansehe, wird da jeden Tag an jeder Ecke gedreht und geschraubt, dass ist bei weitem nicht ideal und führt immer wieder zu Instabilitäten/Fehlern.

Die Gefahr besteht bei einerm neuen Plugin natürlich auch. Wobei ein Neuanfang natürlich den riesigen Vorteil von jetzt vorhandenen Erkenntnissen, bisher gemachten Fehlern, neuen Möglichkeiten (vaapi) usw. hat.

Zitat

Original von wbreu
Ich hoffe, man kann dich doch noch überzeugen!

Na festgelegt hab ich mich doch auch noch gar nicht. Auch erst mal sehen, was noch so für Meinungen/Vorschläge kommen. Mitmachen würde ich denke ich aber auf jeden Fall, hab ja jetzt auch schon etliches an Zeit daran verbraucht...

Wie schon erwähnt, vor nächster Woche wird hier nicht mehr allzuviel von mir kommen, wenig Zeit (so ne Art Urlaub, muss auch ab und zu sein ).

Gruss,
Thomas

Zitat

Original von helau
Dann braeuchte man wohl kein Plugin mehr, denn es gibt ja bereits vnsiserver, xine, xineliboutput, streamdev ...

Die bauen aber auf existierenden Playern auf, denen irgendwie auch noch beigebogen wird Bild und OSD vom VDR auszugeben.
Da gibt es natürlich einigen unnötigen Ballast in den Playern, der nicht nötig ist.
Für die VDR-Ausgabe unter X reicht ein Fenster wo das Bild raus kommt.
Ein Menü oder die Möglichkeit diverse andere Videoformate wiederzugeben ist da überflüssig.
Dagegen fehlt den bisherigen HD-Lösungen FRC zB. komplett.

Zitat

Rein aus Performancegruenden waere aber ein direktes Ausgabeplugin hilfreich ...

Rein aus Stabilitätsgründen sehe ich Vorteile bei der Auftrennung.
Wenn der Codec durch Fehler in Signal abstürzen kann (und da bin ich recht sicher, dass er das kann), wird er das auch tun.
Im dümmsten Fall zerlegt es dabei sogar den Grafiktreiber, der dann auch neu geladen werden muss bevor man den VDR neu starten kann.

Die komprimierten Videodaten aus dem VDR an ein anderes Programm zu übertragen dürfte nicht wirklich Leistung kosten.

Zitat

Original von Mreimer
Das gilt nur für diejenigen, die ohnehin einen VDR-Server betreiben. Wer das weder braucht, noch will, spart garnichts, da der VDR an sich nur dann läuft, wenn ferngesehen und/oder aufgenommen wird.

Nein, das gilt für alle bei Aufnahmen (sofern nicht gleichzeitig irgendwas angeschaut wird).
Mein VDR verbringt >70% mit Aufnahmen, ohne dass ich was dabei ansehe. In der Zeit muss kein Player laufen.

Zitat

Original von SHF
Nein, das gilt für alle bei Aufnahmen (sofern nicht gleichzeitig irgendwas angeschaut wird).
Mein VDR verbringt >70% mit Aufnahmen, ohne dass ich was dabei ansehe. In der Zeit muss kein Player laufen.

Und wie genau handelst du die vielen verschiedenen Fälle ab? Woher weiß dein Player wann er sich starten soll? Der Fall "Aufnahme läuft, aber ich will mich doch zum Live-Schauen aufschalten" ist auch möglich. Hier muss der Player (aber bitte via Fernbedienung!) nachgestartet werden.

Das einzige, das mir wichtig ist, falls eine neue Lösung kommt, wäre bedingungslose Stabilität und vielleicht noch einfache Einrichtung. Beides bietet VDPAU im Moment nur bedingt. Der Einrichtaufwand geht weit über "Hardware einbauen und Plugin installieren" hinaus und über die optimale Auswahl der Parameter gibt es immer noch dann und wann Diskussionen. Zudem findet sich immer mal wieder ein Thread "xine stürtzt ab" oder ähnliches.

Optimal und am einfachsten stabil zu kriegen wäre ein möglichst kleines Stückchen Software, welches vom VDR aus möglichst direkt und mit minimalem Ballast die libva anspricht. Jede Codezeile, die zu viel ist, könnte eine Codezeile sein, in der später ein Bug zu fixen ist.

XBMC kann ohne Probleme OSDs darstellen, weil das fertig dekodierte und gerenderte Frame aus dem VDPAU Surface in ein OpenGL Surface kopiert wird, wo es dann nach belieben weiterverarbeitet werden kann. Nicht die einfachste Methode und für ein VDR Ausgabedevice überdimensioniert. Wenn das bei VAAPI (noch) nicht geht, wird es hoffentlich noch nachgereicht.

Ich habe mich kürzlich mal in VDPAU Schnittstelle eingelesen, damit etwas zu bauen ist sehr einfach, setzt halt ein wenig Wissen über den Aufbau der Datenströme voraus. Bis auf das Stream decoding mach VDPAU absolut alles allein, von der Videodekodierung bis zur Anzeige. Ein OSD zu implementieren sieht zumindest auf den ersten Blick sehr einfach aus. Ich vermute, dass es bei VAAPI ähnlich ist.

Mein größeres Problem mit VAAPI ist der in allen Implementierungen fehlende Deinterlacer. Ob von ATI etwas kommt (da geht nur Bob soweit ich weiß) steht noch in den Sternen und Intel lässt auch auf sich warten. Ohne diese Funktionalität ist das Ganze ziemlich wertlos.

Zitat

Dagegen fehlt den bisherigen HD-Lösungen FRC zB. komplett.

Was genau verstehst du unter FRC? Frame Rate Correction/Control? Was soll die leisten?

Zitat

Original von Mreimer
Und wie genau handelst du die vielen verschiedenen Fälle ab? Woher weiß dein Player wann er sich starten soll? Der Fall "Aufnahme läuft, aber ich will mich doch zum Live-Schauen aufschalten" ist auch möglich. Hier muss der Player (aber bitte via Fernbedienung!) nachgestartet werden.

So habe ich mir das gedacht.
Starten und beenden des Players einfach per UserKey.

Zitat

Das einzige, das mir wichtig ist, falls eine neue Lösung kommt, wäre bedingungslose Stabilität und vielleicht noch einfache Einrichtung.
[...]
Zudem findet sich immer mal wieder ein Thread "xine stürtzt ab" oder ähnliches.

So sehe ich das auch.
Abstürze der Codecs wird man aber wohl nicht völlig verhindern können. Daher bin ich halt für eine Trennung, dann kann man den Player einfach per Knopfdruck neu starten.

Zitat

Original von fwo
Was genau verstehst du unter FRC? Frame Rate Correction/Control? Was soll die leisten?

Hier hat der Meister da selbst die Sache erklärt:
[patch] RGB/PAL ueber VGA mit variabler Framerate

Ob das wirklich mit VAAPI umzusetzen ist bin ich aber überfragt.
Die Erwähnung sollte primär dazu dienen zu Illustrieren, dass die existierenden Player auf alles mögliche optimiert sind, nur nicht auf live TV.

Zitat

Original von wbreu
- Finden sich ein paar Leute die so ein PLUGIN bauen können/wollen?

Bei mir scheitert es wohl am können.
Ich bastele schon von Zeit zu Zeit am LCDproc-Plugin und bin schon da auf der VDR-Seite immer am knabbern :(.

Um mal meinen Senf dazuzugeben: Auja - bitte !!! Aber: Softdevice like ohne abschaltbares Frontend: Bitte nicht. Was die Idee angeht den client auf einem anderen Rechner zu haben: Interessiert mich nicht wirklich, aber wie SHF schrieb, an und abschalten des "Decoder und OSD Anzeigers" wäre für mich Basisanforderung. Schlank/Einfache Konfiguration eine weitere. Player: Bitte in einem seperaten Plugin, wenn das irgendwie vorstellbar ist.

Ich verstehe ja den Wunsch eine Oberfläche aus einem Guß haben zu wollen, aber zumindest ich persönlich möchte mich nicht (mehr) darauf beschränken müssen.

HD-OSD fehlt auch ...

Beiträge ? Von mir wenn dann seelisch/moralisch/finanziell - Programmieren ? Fehlanzeige ...

Wenn man das als Auftragsarbeit/Diplomarbeit wie auch immer gestartet bekommen würde ... wäre schön.

Grundsätzlich wäre ich auch für ein Plugin aus 'einem Guss' und zwar aus verschiedenen Gründen:
- Bei einer Client-Server-Lösung musste ich mich bisher immer mit dem Problem rumschlagen, dass evtl. der Socket noch nicht so weit war, wenn das Frontend starten wollte. Aus diesem Grund habe ich mittlerweile beim Xineliboutput-Plugin die Frontendlib mit eingebunden und sie hat bisher noch kein einziges Mal den VDR mitgerissen, weil sie abgestürzt wäre.
- Als Medienplayer habe ich lieber die einfache und funktionale VDR-Oberfläche als viel grafischen Schnickschnack, den beispielsweise XBMC bietet. Deswegen nutze ich selbst mit Xineliboutput das Mplayer-Plugin, weil es so einfach zu bedienen ist und äußerst stabil läuft. Das neue Libva-Plugin sollte dann noch alle benötigten Slave-Kommandos implementiert haben, das fehlt mir momentan bei Xineliboutput.

Andererseits bietet die Implementierung von Libva in die Xine-Lib viele kurzfristige Vorteile:
- Wie man an Thomas' Bemühungen erkennen kann, sicher am schnellsten greifbare Ergebnisse, weil nicht an vielen Stellen das Rad neu erfunden werden muss.
- Thema Deinterlacer: Da ja abzusehen ist, dass hardwaremäßig in die XVBA-Lib so schnell nichts implementiert wird, muss man halt, auch wenn es CPU-Zeit kostet, auf Softwaredeinterlacer ausweichen. Was nützt es, wenn nichts anderes Vernünftiges möglich ist? Auf jeden Fall bietet Xine über die TVTime-Deinterlacer für jeden Geschmack bzw. jeden CPU-Dampf passende Alternativen. Und wer mit der effektiv halbierten vertikalen Auflösung leben kann-will-muss, nutzt halt den BOB-Deinterlacer von XVBA.
- Für alle, die eine eine Client-Server-Lösung wollen, gibt es Lösungen und man kann auch alles mit einem Plugin ohne extra Player-Frontend installieren.

Allerdings hat die Xine-Lösung natürlich weiterhin die kritisierten Nachteile des schwer administrierbaren Kolosses, dessen Lib an vielen Stellen noch eine einzige Baustelle ist. Aber für die ersten Gehversuche begrüße ich sehr, dass erst einmal etwas Vorhandenes genutzt wird und hoffe, dass Thomas recht bald Zeit findet, an seiner Lösung weiter zu arbeiten