integration von vdpau in vdr

Sieht gut aus, mit dem Patch r181 ist der Ton jetzt synchron.

Gerald

Zitat

Sieht gut aus, mit dem Patch r181 ist der Ton jetzt synchron.

ist ja Klasse wie dieses Projekt vorangeht:tup

so macht budget-based HDTV Spass:)

die eHD wird also langsam ueberfluessig?

Zitat

Original von sparkie
die eHD wird also langsam ueberfluessig?

Das ist wahrscheinlich Ansichtssache, ich habe keine und werde mir auch keine kaufen.
Es funktioniert noch nicht alles, z.B. das Flackern nach dem Kanalwechsel mit software scaling,
und Probleme mit composite und dadurch kein hud, aber ich kann damit leben.
Allerdings habe ich auch nur SDTV.

Gerald

Hallo zusammen,

es gibt neues an der Nvidia-Treiber-/VDPau-Front:

http://www.nvnews.net/vbulletin/showthread.php?t=122606

http://www.jusst.de/vdpau/log.php?repname=xine-vdpau&path=%2F&rev=0&isdir=1

Was mir noch so aufgefallen ist, beim Umschalten von Anixe HD auf ARD und dann gleich auf ZDF, stürzt der VDR ab.
Ebenso beim Umschalten von einem anderen HD-Programm auf andere zwei SD-Sender, wie oben beschrieben.

Kann das bitte mal einer nachvollziehen!?

Danke

Gruß
Wolfgang

Zitat

Original von wbreu
http://www.jusst.de/vdpau/log.php?repname=xine-vdpau&path=%2F&rev=0&isdir=1

Das hatte ich schon gesehen, aber da ich mir bei einigen Fixes keinen
Reim draus machen konnte, wofür das gut sein soll und auf #xine-vdpau
auch keiner anzutreffen war, der das erklären konnte, habe ich das noch nicht
benutzt.
Hat es bei dir etwas verändert?

Gerald

Zitat

Original von gda

Das hatte ich schon gesehen, aber da ich mir bei einigen Fixes keinen
Reim draus machen konnte, wofür das gut sein soll und auf #xine-vdpau
auch keiner anzutreffen war, der das erklären konnte, habe ich das noch nicht
benutzt.
Hat es bei dir etwas verändert?

Gerald

Alles anzeigen

Hi,

jepp ich habe den Eindruck, dass insgesamt das Umschaltverhalten stabiler und das Erkennen beim Umschalten ob SDTV oder HDTV schneller geschehen.

Gruß
Wolfgang

Zitat

Original von wbreu
Hi,

jepp ich habe den Eindruck, dass insgesamt das Umschaltverhalten stabiler und das Erkennen beim Umschalten ob SDTV oder HDTV schneller geschehen.

Gruß
Wolfgang

hallo,

den eindruck habe ich auch - beim (heftigen) zappen - insbesondere von HD auf SD - stürzt mir vdr-sxfe ab (nicht aber der vdr). im einsatz sind:

* xineliboutput 1.0.3
* xinelib-1.2 HG 2009-01-26 (+ xine-lib-1.2-vdpau-r193.diff)
* nvidia-driver 180.25
* vdr-1.7.0

SD und 720P material sieht sehr ok, aus - 1080i ruckelt nach wie vor (aktiviert ist dabei tvtime use video_out driver als deinterlacer). in .xine/config bzw. .xine/config_xineliboutput steht:

video.driver:vdpau
video.output.vdpau_deinterlace_method:temporal_spatial

ansonsten ist vdpau-seitig dort nichts aktiv (habt ihr das anders?). also rein mit diesen einstellungen und im xineliboutput setup nichts (kein deint. bzw. software-scaling) aktiv, gibt's heftiges interlacing (allerdings ist 1080i dann auch flüssig). es scheint so, daß "video.output.vdpau_deinterlace_method:temporal_spatial" nicht greift oder keine wirkung zeigt (ist das bei euch auch so?).

hab's auch mit xine-ui probiert - genauso starke interlacing-treppen, auch mit aufrufparameter "--deinterlacing" (xine-ui zeigt auch an "Deinterlacing" aktiviert -- aufruf mit: xine -f -g -D -V vdpau --no-logo "xvdr+tcp://127.0.0.1:37890#nocache;demux:mpeg_block")

die AMD-CPU ist bei der ganzen testerei immer auf 2300MHz getaktet.

und noch eine frage ;): macht ihr das irgendwie anders?

gruß, ciax

Zitat

Original von ciax

und noch eine frage ;): macht ihr das irgendwie anders?

Ich kann nicht wirklich helfen, weil ich ja nur SDTV habe.
Ich benutze --post tvtime:method=use_vo_driver für vdr-sxfe und
habe definitiv keine .xine/config, oder .xine/config_xineliboutput und
habe keine deinterlace Probleme.

Mein Prozessor läuft dabei immer wenn ich mal nach sehe auf
1800 MHz. 2300 MHz kann er ja auch gar nicht. Die 1800 MHz
hat er auch nur weil das Graphtft-Plugin soviel Last macht.
Gestern habe ich gesehen, dass das wahrscheinlich an der Animation vom
REC-Symbol liegt, das werde ich heute mal abschalten.

Gerald

ok - danke Gerald,

bei SDTV und 720P geht's ja eigentlich ganz gut (mit den selben einstellungen: --post tvtime:method=use_vo_driver).

wenn ich halt einmal auf einen 1080i schalte, kann ich's mit dem o.a. deinterlacing nicht flüssig bringen (obwohl die cpu bei so 10-25% rumtümpelt).

frag' mich nur, was das "video.output.vdpau_deinterlace_method:temporal_spatial" bringen soll ??

gruß, ciax

Hallo CIAX,

welche Grafikkarte bzw, welches Board mit IGP benutzt Du?

Ich tippe mal hier liegt der Hund begraben.

Solltest Du ein GF8200/8300 Board mit Deiner CPU aus der Signatur einsetzen versuche mal BOB Deinterlacing zu erzwingen :

Zitat

video.output.vdpau_deinterlace_method:bob

viel mehr als BOB sollte mit einer Kombi aus GF8200/8300 Board und einer K8 CPU nicht möglich sein, dann hilft nur eine K10 CPU.

grüße

hallo vdr.tuxnet,

auf BOB habe ich gestern abend noch umgestellt - bringt tatsächlich mit meiner kombi zuhause das beste ergebnis .. dabei ist es hier allerdings völlig egal, ob die CPU (BE-2400) auf 1000, 1800 oder voll auf 2300MHz läuft.

meine GPU ist eine 9400GT (G96/D9M / 550 MHz core) - hab' das ganze verhalten auch im nvnews forum gepostet und "jusst" meinte, daß nur die stärksten GPUs den algorithmus "temporal_spatial" packen, mit meiner sollte "temporal" gut möglich sein - geworden ist's nun vorab einmal "bob"

so rein "subjektiv", erscheint's mir nun wirklich seit gestern schon recht "stabil" zu laufen ..

gruß, ciax

Hallo,

gut das es funktioniert!

Meine Lösung mit der K10 CPU ist ja komplett OVERSIZED, hier ist temporal_spatial zwar möglich doch auf Grund des Energieverbrauches unlogisch ich bin jetzt auch zurück auf die K8 CPU und lebe mit BOB.

Dann hoffen wir mal auf andere Lösungen in der Zukunft, eventuell sparsame
K10 CPUs oder komplett neue Lösungen für den HTPC Hardwarebereich, die nötige Software ist ja fast den Kinderschuhen entwachsen.

Gruß

.. das mit der CPU (K8 bzw. K10 oder so) kapier ich nicht ganz - die ist auch beim K8 nicht ausgelastet .. gerade wg. VDPAU eben

die GPU muß mit dem deinterlacing-algo zurecht kommen, ok -- doch mit VDPAU sollten ja gerade schwachbrüstige CPUs zum fahren kommen können ...

gruß, ciax

Zitat

Original von ciax
.. das mit der CPU (K8 bzw. K10 oder so) kapier ich nicht ganz - die ist auch beim K8 nicht ausgelastet .. gerade wg. VDPAU eben

die GPU muß mit dem deinterlacing-algo zurecht kommen, ok -- doch mit VDPAU sollten ja gerade schwachbrüstige CPUs zum fahren kommen können ...

Ich weiß leider nicht mehr genau wo ich das gelesen habe, aber ich habe
jedenfalls verstanden, dass es nicht an der schnelleren CPU sondern
am HT3 liegt. Die GPU muss zum Zugriff aufs RAM den Memory-Controller
der CPU nehmen (im Gegensatz zu Intel CPUs, die den Memory-Controller ja nicht eingebaut haben) und erst der HT3 der K10 CPU kann die Daten
schnell genug liefern ohne die CPU komplett auszubremsen.

Gerald

Was dann bedeuten würde, dass selbst das temporal_spatial deinterlacing mit einer billig IGP und einer billig Intel CPU laufen würde, weil der Memory Controller in der Northbridge sitzt? Dann wäre das ja die deutlich zu bevorzugende Lösung wenns um vdpau geht.

Zitat

Original von dortje
Was dann bedeuten würde, dass selbst das temporal_spatial deinterlacing mit einer billig IGP und einer billig Intel CPU laufen würde, weil der Memory Controller in der Northbridge sitzt? Dann wäre das ja die deutlich zu bevorzugende Lösung wenns um vdpau geht.

Jepp,

genau so ist, ich kann bei einem Prozessorwechsel in meinem System 2 keinen Unterschied feststellen, bei gleicher Konfiguration.

Die Intel Celeron 440-CPU macht das mittlerweile sehr schön.

Mit AMD-Systemen scheint es doch ein wenig komplizierter zu sein.

Wolfgang

Zitat

Original von dortje
Was dann bedeuten würde, dass selbst das temporal_spatial deinterlacing mit einer billig IGP und einer billig Intel CPU laufen würde, weil der Memory Controller in der Northbridge sitzt? Dann wäre das ja die deutlich zu bevorzugende Lösung wenns um vdpau geht.

So könnte man argumentieren. Da allerdings eine K10-CPU recht günstig zu
bekommen ist, relativiert sich das etwas. Da ich ja erstmal mit SDTV
auskomme und das Problem nur mit HDTV auftritt, kann ich warten, bis
die K10s mit niedrigerem Stromverbrauch rauskommen.

Gerald

lt. zitat "jusst" aus dem nvnews-forum:

Zitat

The CPU has no influence on VDPAU performance. The deinterlacing is done in the GPU Shader Units so it just depends on the GPU.

zu gut kenn' ich mich mit der materie nicht aus - eine anwendung des HT wäre der direkte zugriff (DMA) auf den Systemspeicher. ist das jetzt nur relevant für onboard-GPUs, die systemspeicher nutzen oder auch für addin-karten, die selbst ihren speicher mitbringen .. ?

naja, wenn's "temporal_spatial" bei wbreu mit einer "schwächeren" celeron cpu läuft, scheint's doch AMD-spezifisch zu sein ...

grüß,
ciax

.. hab nochmal im nvnews-forum gefragt. lt. meinung eines xine-vdpau entwicklers, stellt sich für ihn die sache folgend dar:

Zitat

For onboard graphics chipset the memory performance is very relevant... For dedicated cards the work will be going on the graphics card memory anyway.

so klingt das auch für mich logisch

Zitat

Original von ciax
.. hab nochmal im nvnews-forum gefragt. lt. meinung eines xine-vdpau entwicklers, stellt sich für ihn die sache folgend dar:

so klingt das auch für mich logisch

Was letztendlich heißt, dass ein AMD-Board mit einer einfache NVIDIA-Karte im PCI-E doch die günstigste Lösung sein sollte.

hemonu