Reines Ausgabeplugin für libva mit dem VDR?

Das wäre doch etwas für einen neuen Test VDR. Bin dabei.

Ich hätte auch bereits eine Idee:

VDR + zwei Plugins:

Vnsiserver für den Videostream da der schon sehr gut auf Performance optimiert ist und den Videstream soweit ich das gesehen habe auch schon so aufräumt dass ihn ein ffmpeg-basierender Player abspielen kann (zumindest gibt es im Source davon Demuxer-Klassen und XBMC kann den Videostream abspielen )

zweites neues Plugin:
Plugin dass auf eine TCP-Connection wartet (passive open) und der neue Client der dadurch dann die Informationen zum OSD erhält.

der Client:

verwendet die libplayer vom enna projekt (sofern diese Lib nicht das E17-Framework benötigt) und im Hintergrund verwenden wir damit einen auf vaapi gepatchten mplayer um die Streams vom vnsiserver-plugin abzuspielen
die OSD-Informationen werden nicht in das Video eingebettet sondern nun via OpenGL+SDL (oder alternativ OpenGL+Allegro) darübergelegt
-> hätten den Vorteil dass das Video nie wieder ruckelt wegen des OSD und man auch alternativ ein schöneres OSD auf OpenGL-Basis erstellen könnte

so bin wieder afk lernen aber die Idee musste ich noch loswerden!

mfg
aelo

aelo, du vestehst das wohl falsch. Es ist ein Ziel des neuen Plugins, keine Client-Server Kombination zu haben. Darum wird ja auch nicht Xine erweitert, sondern ein eigenes Plugin gebaut.

Kann mir mal jemand einen Link zu dem VA-API VDPAU Backend schicken/posten?

aelo

Copperhead hat Recht, es geht darum den Zweiteiler verbunden über Fifo, Socket loszuwerden und die Wahl der nutzbaren Grafik-HW deutlich zu erweitern. Man könnte dann Intel, ATI, Nvidia und ich meine sogar S3 GPUs nutzen.

@all

Wenn man es mit etwas Bestehendem vergleichen möchte, könnte man sich "softdevice" anschauen, kein Fifo oder Socket, also integrierte Bildausgabe. Die Ausgabe erfolgt wahlweise über Xorg, leider ging die Entwicklung nie über Xv raus, oder Framebuffer, hierbei mit DFB oder Vidix als Grundlage.

Und da hat wohl "tbshl-vdr" Recht, ohne einen solchen Unterbau wird es wahrscheinlich nicht gehen.

Gruß
Frank

d.h. ihr schlagt vor etwas zu implementieren dass die Ausgabe am besten gleich in einen Buffer der GPU schreibt?
hätte das nicht zur Folge dass es dann nicht mehr als Desktop-Applikation verwendet werden kann? fände ich schade, gerade dann wenn noch keine Medien abgespielt werden wäre damit ein Wechsel zu z.B. XBMC dann doch ziemlich umständlich?

was ist denn an einer Client/Server so schlimm? wenn sie "ordentlich" implementiert wird wie z.b. im VNSI Server dann sind auch die Umschaltzeiten spitze

die FIFO-Lösung ist natürlich nicht so super, aber gegen ein TCP-Socket spricht doch außer der etwas komplexeren Streamverarbeitung nicht wirklich etwas? oder täusche ich mich und bedenke da etwas nicht? (lasse mich gerne korrigieren)

mfg
aelo

edit: mplayer z.b. hätte den Vorteil dass wirklich jede Videobeschleunigungsmethode die man möchte ohne großen Aufwand verwendet werden könnte
und OpenGL ermöglicht ein OSD dass immer gleich groß ist, nicht pixlig aussieht auch wenn dahinter ein PAL-Sender läuft usw...

Client-Server hat ein weiteres Fehlerpotenzial. Der VDR soll ja eigentlich gar keine Desktop-Anwendung sein. Siehe FF-Karten.

Und mit einer FF-Karte kann man das hier glaube ich ganz gut vergleichen. Stabilität bis zum Abwinken. Keine verrückten Fehler, bei denen keiner den Fehler findet. Keine unnötigen Puffer etc.

Wie wäre es wenn du es akzeptierst, das es so geplant ist, und alle außer dir dafür sind?!

natürlich akzeptiere ich das, steht hier nicht zu frage
bin nur am WIESO interessiert denn nur so kann man dazu lernen!

mfg
aelo

Naja das wieso habe ich dir ja schon versucht zu erklären.

Früher gab es die Full-Featured Karte die war stabil wie die sau, bzw ist es noch.

Jetzt nutzt man hauptsächlich VDPAU, das mit einem Client/Server Konzept betrieben wird. Immer öfter treten Fehler auf, die sich keiner erklären kann und oft nur schwer gelöst werden.

Das liegt meines Wissens nach an den vielen verschiedenen Stellen, an denen man VDPAU "kaputtspielen" kann.

Das Plugin das in diesem Thread entstehen soll, soll wieder diese unglaubliche Stabilität einer alten full-Featured-Karte haben.

wbreu: Gut erklärt oder übers Ziel hinausgeschossen?

Quote

Wie wäre es wenn du es akzeptierst, das es so geplant ist, und alle außer dir dafür sind?!

scheint ja sicher zu sein, dass du es auch programmieren willst.

Programmieren weniger, eher finanziell oder in anderer Weise (Da fallen mit Sicherheit auch andere Jobs an) unterstützen.

Quote

Original von aelo
d.h. ihr schlagt vor etwas zu implementieren dass die Ausgabe am besten gleich in einen Buffer der GPU schreibt?
hätte das nicht zur Folge dass es dann nicht mehr als Desktop-Applikation verwendet werden kann? fände ich schade, gerade dann wenn noch keine Medien abgespielt werden wäre damit ein Wechsel zu z.B. XBMC dann doch ziemlich umständlich?

Und nicht nur das...
Für mich ist seit kurzem auch ein Web Browser fester Bestandteil meines HTPC's. In der Werbung mal schnell das TV Fenster minimieren und ein bisschen im Internet surfen finde ich schon sehr komfortabel.

Trotzdem ein sehr guter Ansatz auch mal die ATI Hardware besser nutzten zu können! Hätte man die zusätzliche Grafikkarte nicht im System, könnte man mit viel dünneren/schöneren Gehäusen auskommen, z.B. Silverstone LC19...

Wenn ich das richtig sehe hat vaapi aber wohl kein osd vorgesehen

Quote

Due to the lack of implementation of subpicture blending in current VAAPI drivers, no OSD is available for the new video output.

Zumindest im Bereich VDPAU wäre ohnehin der X-Server nötig. Es würde nichts dagegen sprechen ein Full-Screen-Fenster aufzuziehen und darin das Video abzuspielen. Den Browser könnte man dann ggf. immer noch aufrufen. Er würde dann über diesem großen VDR-Fenster landen und dieses überdecken.

Was die Medien-Abspielerei angeht, wäre hier eher das richtige Ziel z.B. das MPlayer-Plugin auszubauen und zu erweitern. VDR hat selber ein OSD, ein Skin-System und ein Plugin-System. Es geht mir zuwieder, da parallel was laufen zu lassen. Lieber würde ich den Player aus dem VDR-OSD heraus bedienen.

helau
Keine Ahnung ob es da nicht doch Lösungen gibt. Kann z.B. VAAPI und OpenGL gemischt genutzt werden?

Quote

Original von wbreu
@all, wie sieht es denn jetzt mit konkreten "Ja, ich wäre dabei beim Programmieren aus" ?

Bin grade dabei, das mal in xine-lib einzubauen.

...
load_plugins: plugin /usr/lib/xine/plugins/2.0/post/xineplug_post_autocrop.so found
load_plugins: plugin /usr/lib/xine/plugins/2.0/xineplug_dmx_fli.so found
load_plugins: plugin /usr/lib/xine/plugins/2.0/xineplug_decode_yuv.so found
libva: libva version 0.31.0
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/dri/nvidia_drv_video.so
libva: va_openDriver() returns 0
VAAPI initialized, Vers. 0.31
VAAPI - attrib 5 (get/---) min 0 max 0 value 0x0
VAAPI - attrib 0 (get/set) min -100 max 100 value 0x0
VAAPI - attrib 1 (get/set) min -100 max 100 value 0x0
VAAPI - attrib 2 (get/set) min -100 max 100 value 0x0
VAAPI - attrib 3 (get/set) min -100 max 100 value 0x0
VAAPI - attrib 4 (get/set) min 0 max 16777215 value 0x0
audio_alsa_out : Unterstützte Modi sind 8Bit 16Bit 24Bit 32Bit Mono Stereo (4-Kanal nicht aktiviert in xine Konfiguration) (4.1-Kanal nicht aktiviert in xine Konfiguration) (5-Kanal nicht aktiviert in xine Konfiguration) 5.1-Kanal (a/52 und DTS pass-through nicht aktiviert in xine Konfiguration)
Available video drivers: vdpau vaapi xv raw opengl xshm caca aa xxmc none sdl fb xvmc
...

Mehr als die lib zu initialisieren ist aber noch nicht, das kann auch noch etwas dauern...

Gruss,
Thomas

Quote

Original von wbreu
Zudem, wie im Eingangspost schon angesprochen, vdpau ist nur für Nvidia, was ist denn wenn da nichts mehr kommt, => und das ist zu Befürchten!

Spielst du da auf was spezielles an?

Quote

Original von wbreu
inwieweit kann man dich denn mit Hardware unterstützen => Intel oder Ati/AMD?

Momentan kann ich ja erstmal mit dem VDPAU-Backend testen, oder besser, muss ich erstmal soweit kommen dass ich überhaupt ne Ausgabe testen kann
Evtl. hab ich doch ne ATI hier die h264 decodiert, bin aber nicht sicher, vielleicht weiss da wer mehr. Ist nicht eingebaut, daher keine Ausgaben, nur vom Karton, da steht RX1550 und TD128EH, HDTV-Ready, DirectX 9.0, OpenGL 2.0. Ahja, in der Anleitung steht "MPEG 1/2/4 decode and encode accerlation", könnte gehen.