[solved] xine und xineliboutput nur ein thread .. wieso ?

threads=3 bringt hier garnix

Ich habe nochmal die xine-lib aus dem hg gezogen und alles neu gebaut. Nun ist die Verteilung über die cores 100%:66% sowohl mit dem xineliboutput Plugin als auch mit Xine Plugin. Zuvor, mit "verbastelter" xine-lib war die Verteilung 100%:25% - also immerhin eine Verbesserung. Bei ArteHD laufen beider cores meines BE-2350 mit ca 85%.

Es liegt also doch an der xine-lib und nicht an ffmpeg.

Gruß, ollo

hi ollo,

naja, nicht die besten nachrichten - bin leider noch immer nicht zum testen gekommen (wenn du das schon gemacht hast, kann ich's mir vermtl. sparen - wird sich gleich verhalten).

mit dem BE-2350 wird's bei deiner angeführten verteilung auch kein spaß sein, HD zu gucken

edit on:
oder meinst du mit 100%:66%, daß der prozess vdr-sxfe/xinelibouput bzw. xine sozusagen mit 166% läuft. hier kommt der nicht über 100% hinaus und ein core ist am dampfen .. )
edit off:

OT on:
weil du arte HD erwähnst: könntest du so nett sein und deinen channels.conf eintrag kurz posten. hier hab ich:

arte HD;ZDFvision:11362:hC23M5O35S1:S19.2E:22000:6210:6221=deu,6222=fra:6230:0:11120:1:1011:0

damit gibt's heftige "quitscher im ton und artefakte" beim "ein-syncen". oft bekomme ich gar keinen empfang - mich wundert schon lange, warum das so ist.
OT off:

gruß, ciax

ps: in der xine-user ML gibt's ad dato (leider) noch keine reaktion ...

Hi ciax,

die 720p laufen recht vernünftig, die 1080i ruckeln aber.

Hier der gewünschte Eintrag aus meiner channels.conf - hat der VDR selber eingetragen:

arte HD;ZDFvision:11361:hC23M5O35S1:S19.2E:22000:6210:6221=deu,6222=fra:6230:0:11120:1:1011:0

Gruß, ollo

.. danke ollo!

gibts was neues von der front? arte hd tuts hier eins a..

Zitat

Original von infinite
gibts was neues von der front? arte hd tuts hier eins a..

Hallo infinite,

nada,

habe gestern abend mal aktualisiert, also die xinelib, und xineliboutput, jeweils die aktuellen cvs-Versionen.

Gruß
Wolfgang

:moin,

wbreu & ciax, könntet ihr bitte mal beschreiben wie ihr ein minimales X für die Ausgabe per xineliboutput startet - also ohne gdm usw?

Übrigens bringt der fglrx 8.8 keine Besserung, der komplette X-Server schmiert mir beim Umschalten ab wenn ich Xv verwende. Allerdings liegt die load bei AstraHD mit Xv bei ~60% gleichverteilt auf beiden cores.

Tja, es könnte alles so einfach sein - ist es aber nicht...

Gruß, ollo

hi ollo,

ich starte einfach über ein minimal-init-script X über xinit. so sieht's hier aus:

#! /bin/sh
#
# init.d script to start xinit with graphTFT and vdr-sxfe
#
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
sleep 5
logger __ Now starts VDR_XINIT __


/usr/bin/xinit -e /opt/src/vdr/vdr-1.7.0-live/PLUGINS/src/graphtft/graphtft-fe/graphtft-fe -h localhost -e 2 -n -W 640 -H 480 -f -r & su - -c "/opt/src/vdr/vdr-1.7.0-live/PLUGINS/src/xineliboutput/vdr-sxfe --verbose --reconnect --display=:0.1 --fullscreen --video=xv --aspect=auto --audio=alsa xvdr+tcp://localhost" ciax


exit 0

ist nicht schön, funktioniert hier aber -- den graphtft-teil bis nach dem "&" kannst du vergessen.

ich mußte allerdings vdr-sxfe unter einem anderen user (ciax) als root laufen lassen. siehe hier --> [solved] xineliboutput: kernel segfault beim start via init

Zitat

Übrigens bringt der fglrx 8.8 keine Besserung, der komplette X-Server schmiert mir beim Umschalten ab wenn ich Xv verwende. Allerdings liegt die load bei AstraHD mit Xv bei ~60% gleichverteilt auf beiden cores.

.. heißt das nun, daß der fglrx etwas bzgl. der verteilung bringt (? verwirrt ?). habe hier auch wie wolfgang die letzte xine-lib und's cvs xinelibouput sowie eine aktuelle ffmpeg nachgezogen. bringt allerdings leider gar nichts ...

grüße,
ciax

Hi ciax,

danke für Dein Script, daraus hae ich mit meins basteln können.

Bzgl. der Prozessverteilung denke ich dass es eher mit dem Ausgabedevice zusammenhängt (xv vs. xshm) denn mit dem Treiber.

Wenn man denn nur dem softdevide h.264 "beibringen" könnte

Gruß, ollo

ich grabs nochmal aus: any update?

Zitat

Original von infinite
ich grabs nochmal aus: any update?

nep - aus der xine-ml auch nichts. hab's problem ja damals dort noch gepostet. leider ..

ps: .. bin noch mit "xine-lib-HG-2008-08-18" unterwegs.

Zitat

Originally posted by Rincewind99
Mit Problem meinte ich aber, dass die Rechenlast bei mir mit 50Hz Modelines deutlich höher liegt als mit 60Hz.

zwar schon ein Weilchen her, aber ich hab's erst jetzt gesehen. Bei 50Hz Modelines hat der ClosedSource nVidia Xserver wirklich ein Problem. Das liegt offenbar daran, dass hier per default ein BusyWait auf den VBLANK gemacht wird.
Wenn die Modeline 60Hz hat ist das kein grosses Problem, da im zeitlichen Mittel nur 10ms auf den VBLANK gewartet werden muss. Die Wartezeit ist dabei noch ziemlich gleichverteilt.

Bei einer 50Hz Modeline bildet sich aber, wenn 25Hz/50Hz Material abgespielt wird, eine sehr langsame Schwebungsfrequenz zwischen beiden aus. Es muss kurz vor dem naechsten Frame/FieldDrop bei *jedem* Voll/Halbbild bis zu 20ms gewartet werden. Ich kann das sogar mit 'vmstat 2' beobachten, wie die CPU Last periodisch im Takt der Schwebung stetig bis auf nahezu 80% ansteigt um anschliessend wieder auf die durch den Decoder/Deinterlacer verursachte Grundlast abzufallen. Das passiert bei mir schon bei SD Material.

Abhilfe schafft hier bei mir

Option "UseEvents" "True"

zu setzen. Das macht anscheinend nen Syscall und gibt die CPU frei. Hat aber wiederum den Nachteil, dass der Xserver nicht mehr so schnell auf Maus/Tastatur Eingaben reagiert. Merkt man auf langsameren Maschinen.

Hi Sparkie,

Option "UseEvents" "True"

habe ich in der xorg.conf gesetzt. Macht aber leider keinerlei Unterschied. Das Verhalten bei mir ist genau das von dir beobachtete.

Ich verfolge das aber nicht weiter, weil ich darauf hoffe, dass der xorg radeon Treiber demnächst auch XV auf meiner on board HD3200 unterstützt - warum sollte ja klar sein

Grüße,
Matthias

Zitat

Original von ollo
[..]Reinhard Nissl wäre bzgl. xine-lib sicher eine große Hilfe - kommt, wir rufen ihn alle mal

Reinhard hat sich wieder in vdr-dev eingeklinkt .. eventuell stolpert er ja auch über diesen/s thread/problem ... aus der xine-user ML meldet sich ja niemand bzgl. dieses problems ...

--> vdr ML: klick