VDPAU und die "Hänger" bei HD. Wie ist der aktuelle Stand? Teil 2

Habt Ihr schon TCP verwendet bzw getestet? Ich habe nie Pipes versucht.

Johns

Hmm... ich starte das Ganze mit dem runvdr-extrem Script z.B. so:

nice --5 xine -f -B -G 1360x768 -V vdpau -A alsa --post vdr --post vdr_video --post vdr_audio --post autocrop:use_avards_analysis=1,overscan_compensate=30,soft_start=0 --aspect-ratio=auto --verbose=2 --no-gui --no-logo --no-splash vdr://tmp/vdr-xine/stream#demux:mpeg_pes 1> /var/log/xine.log

Die von dir vorgeschlagene Variante über TCP funktioniert doch nur mit xineliboutput und vdr-sxfe, oder seh ich da was falsch? Zumindest hab ich das nur mit letztgenannten hinbekommen....?!

Gruß
iNOB

hier auch gleiches Problem (kurzes Standbild und dann schneller Vorlauf) mit dem VDR aus der Signatur.

Zitat von iNOB

Das Problem ist existent auf ATOM-Boards mit ION-Chipsatz und auf Systemen mit GT210 Grakas. Würde mich wundern, wen das auf einem System mit GT430 anders wäre.

Gruß
iNOB

Karte ist gestern geliefert worden (allerdings bin ich nicht der Tester) am WE wissen wir hoffentlich mehr.

im Erfolgsfall geb ich dann eine meiner Asus GT520 ab, dann bin ich gleich das Servus TV Problem mit los

Ich bin gespannt. Wenn die 430er klappt muss ich mir was einfallen lassen...

also ich hab jetzt auch seit heute ne passive Asus GT430 in meiner Hauptmaschine, der Kollege hat ne Sparkle wegen der LP Option.

Bis jetzt super:
kein Ruckeln,
temperaturen auf 1080i temp spatial marginal niedriger als mit mit G210(128-bit Memory Inteface) und auch GT520,
zum erstenmal kein Ruckeln auf zeitlich/räumlich in xbmc,
anders als mit der GT520 funkioniert Servus TV nicht nur manchmal

...man merkt auch am sichtbar weniger ruckelnden anthra das die GraKa wesentlich mehr Dampf hat!

ich beobachte das weiter, am WE hab ich bestimmt einen sichereren Eindruck. Ich lass die Karte in jedem Fall drin, eine meiner beiden GT520 steht ab sofort zum Verkauf

Christian

CKone
Ruckelte das Wochenende?

Sent from my Galaxy Nexus using Tapatalk

also es ist subjektiv fast weg, sagen wir es hat sich von 95% auf 99% perfekt verbessert!

XBMC in jedem Fall ist, wenn auch weiterhin etwas unergonomisch, mit temp spatial jetzt auch Bildtechnisch ne xine Alternative, dazu reicht die GT520 einfach nicht...

Temperaturtechnisch würd ich sagen ein hauch kühler als die GT520 (5-8Grad), wobei das auch damit zusammen hängen kann das ich die Netze vor den Lüftern ausgesaugt hab

Ich hab zwischenzeitlich auch die Zweitaschine mit ner GT430 ausgestattet und würde sagen das wir abgesehen von noad/markad gerade ganz nah an der Perfektion eines alten SD FF vdr kratzen....

Hi,

Zitat von CKone

Ich hab zwischenzeitlich auch die Zweitaschine mit ner GT430 ausgestattet und würde sagen das wir abgesehen von noad/markad gerade ganz nah an der Perfektion eines alten SD FF vdr kratzen....

Genau so schaut's aus, der VDR wird immer perfekter
Was ich ehrlich gesagt nicht verstehe, eine schwächere Graka zu verbauen, nur weil die etwas weniger Strom zieht.
Preis/Leistungmässig ist die GT430 gerade das optimale - mit meiner alten GT220 habe ich allerdings auch keine Probleme.

BTW: Kann mir jemand verraten woher diese Log's (VDR Log LEVEL 3) kommen :

Dec 21 19:14:12 linux-q7w9 vdr: [2154] [demux_vdr] ts2es: no payload, size 0
Dec 21 19:14:13 linux-q7w9 vdr: [2154] [demux_vdr] ts2es: no payload, size 0
Dec 21 19:14:29 linux-q7w9 vdr: [2154] [demux_vdr] ts2es: no payload, size 0
Dec 21 19:14:34 linux-q7w9 vdr: [2154] [demux_vdr] ts2es: no payload, size 0

Dies habe ich schon länger auf diversen Systemen (bei Log Level3), Der VDR läuft prima - nur müllt dies den Log voll.

Gruß Rudi

Zitat von rudirabbit

Was ich ehrlich gesagt nicht verstehe, eine schwächere Graka zu verbauen, nur weil die etwas weniger Strom zieht.
Preis/Leistungmässig ist die GT430 gerade das optimale - mit meiner alten GT220 habe ich allerdings auch keine Probleme.

Dem kann ich nur beipflichten, die in den letzten Posts beschriebene Experience habe ich seit ich G96 basierte Grafikkarten (32 Cuda Cores) einsetze. Niemals ruckelndes OSD, immer temporal_spatial bei 1080i, tolles Bild und das die Unterschiede in der Leistungsaufnahmen eher gering denn wirklich groß sind haben wir schon 2009/2010 beschrieben. Wobei eine vernünftige CPU schon auch wichtig ist.

Wenn ich aktuell eine Grafikkarten kaufen müßte, würde ich wohl auch eine passive GT430 oben auf den Liste stehen. Die Pro-Version davon habe ich bereits auch hier ab und am im VDR Betrieb, Quadro 600 ...

Regards
fnu

Hi,
Wegen der Log Einträge

Dec 25 18:27:12 linux-q7w9 vdr: [1403] [demux_vdr] ts2es: no payload, size 0

Es passiert in dieser Funktion in der Datei (ts2es.c) vom xineliboutput plugin

buf_element_t *ts2es_put(ts2es_t *this, uint8_t *data, fifo_buffer_t *src_fifo)

Dort wird unter anderem dies geprüft:

if (!ts_HAS_PAYLOAD(data)) {
LOGDBG("ts2es: no payload, size %d", bytes);
return NULL;
  }

Also die Frage: (!ts_HAS_PAYLOAD(data)) wird mit true beantwortet, warum ist dies so ?
Ich habe keine Probleme mit Rucklern etc. - aber der Log wird vollgemüllt.
Oder stimmt was mit der Funktion ts_HAS_PAYLOAD nicht ?

Gruß - und frohes Fest

Bist du sicher das Xine ffmpeg verwendet?
Ich habe das so verstanden, daß xine seinen eigenen h264 Parser hat. Von diesem gibt es zwei Varianten.
Bei Verwendung von Hardwaredecodern, ist es besser nur einen Thread zuverwenden.

Johns

Zitat von jrie

Du meinst, dass mit vdpau der Wert von video.processing.ffmpeg_thread_count egal ist, weil ffmpeg nicht verwendet wird?

Ja, aber hängt von den Prioritäten in config bzw. config_xineliboutput ab:
engine.decoder_priorities.ffmpegvideo
engine.decoder_priorities.vdpau_h264
engine.decoder_priorities.vdpau_h264_alter

Wenn du "engine.decoder_priorities.ffmpegvideo" verändert hast, dann kann auch ffmpeg verwendet werden. Aber normal wird "h264_alter" verwendet.

Johns

Bei mir steht dies im Log:

Dec 31 17:58:47 linux-q7w9 vdr: [1684] [demux_vdr] Using H.264  decoder "vdpau_h264_alter" (FFmpeg)

Also hat der "vdpau_h264_alter" Parser doch was mit FFmpeg tun ?