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

Hallo,

Ich kämpfe momentan ziemlich vergebens mit xineliboutput und den HD Kanälen.

Hardware Athlon X2-4200.
2x satelco easy watch dvb-c

Software:

Kernel 2.6.25.8
VDR-1.7.0 mit h264 Patch
xineliboutput über xv
aktueller nvidia closesource
xinelib 1.14
ffmpeg aus dem cvs

Xinelib und ffmpeg mit obengenannten Optimierungen übersetzt.

SD Kanäle gehen tadellos. HD Kanäle ruckeln immer wieder mal.

Meiner meinung nach scaliert der VDR prozess nicht sauber auf beide Kerne.
Manchmal sieht die Prozessorlast ziemlich gut aus core1 40% core2 60%
Dann geht es wieder mal auf 94% zu 5 %.
Was mir unter top noch auffällt ist, dass diese unter %ni laufen. siehe Anhang

Kann man hier eventuell noch am Kernel was schrauben, oderist ein 42200 einfach zu schwach?

Viele Grüße
Peter

Sorry, ein bisschen off topic:

Hat du eine 50Hz Modeline eingestellt? Und welcher Prozess braucht im 94 zu 5 Fall die Rechenzeit auf dem ersten Core?

Hintergrund: ich habe im SD Bereich ein ähnliches Problem. Bei eingeschaltetem Deinterlacer und nur bei 50Hz Modelines frisst der XServer fast einen ganzen Core. Wechsel ich auf 60Hz ist das Problem weg.

Ich glaube langsam, dass der closed source NVidia Treiber ein Problem hat bei Quellenframerate == Displayframerate.

Viele Grüße,
Matthias

Hallo Mathias,

Steht auf 60 hz.

Die Last zieht der VDR Prozess.
Bei SD Kanälen ist der X-Server kaum merkbar. Bei HD zieht dieser ca. 7 %.

Was mir auffällt ist die Tatsache, dass das schlechte scalieren auf bei SD vorhanden ist. Hier ist es mal 30 zu 2, dann 14 zu 16 und dann wieder 2 zu 28.
Wechselt also genau so, wie bei HD. Hier gibt es allerdings massig reserven.

Peter

Zitat

Original by pixelpeter
Meiner meinung nach scaliert der VDR prozess nicht sauber auf beide Kerne.

stimmt - ist hier auch so (obwohl/trotzdem die HD sender auf transponder 11914 seit ca. 10 tagen nicht mehr "flüssig" laufen - interlaced effekte & kästchenbildung -- scheint irgendwas mit dem encoder/provider decoder/xine,ffmpeg zu tun zu haben) . aber wenigstens sind beide kerne am werken dafür - ob die ungleiche auslastung zu rucklern führt oder so, kann ich fundiert nicht sagen.

Zitat

Original by pixelpeter
Die Last zieht der VDR Prozess.

du läst xineliboutput mit sxfe local laufen? so wird xinelibouput als thread via vdr gefahren - somit geht die last des vdr prozesses rauf. das sollte ok sein.

Zitat

Original by Rincewind99
Ich glaube langsam, dass der closed source NVidia Treiber ein Problem hat bei Quellenframerate == Displayframerate.

das sollte nicht nur nvidia so haben - ist auch bei ati nicht im "upstream" treiber drin (info "RGB/PAL over VGA at variable frame rate" ("sparkie" --> link)

gruß, ciax

ja die haben wohl was rumgeschraubt auf 11914. Werden wohl warten müssen bis das ganze in ffmpeg gefixt wurde.

Zitat

Der auf diesem Transponder verwendete h.264 Encoder ( soll ein Tandberg sein ) wurde vor einigen Tagen verändert, um noch mehr Bitrate zu sparen. Der so erzeugte h.264 Stream enthält jetzt weder IDR- noch I-Frames, sondern nur noch Intra encodete Macroblocks.

Infolge dessen muß der verwendete h.264 Dekoder erstmal solange Frames / Fields sammeln ohne sie anzuzeigen, bis er genügend encodete Macroblocks gefunden hat um damit die Referenzen auflösen zu können. Erst dann kann ein Bild angezeigt werden. Diese Art des Encodens ist im übrigen von der h.264 Norm durchaus zugelassen, hat aber den Nachteil, daß ein random Zugriff auf einzelne Frames erheblich erschwert bis unmöglich wird. Da man aber ( nach Vorstellungen der Contentmafia ) ja ohnehin keine DVB Sendungen aufnehmen soll um sie zu archivieren, stört das bei den Programmanbietern offensichtlich niemanden. Vielmehr kann man sogar mutmaßen, daß die erschwerte Nutzung von Aufnahmen sogar ein wollkommender Nebeneffekt der Änderung ist.

Bei mir kann ich die betroffenen Sender (zwei von vier, da Kabel von KD) sowohl mit CoreAVC Version 1.65, als auch mit dem CL264dec.ax Codec vom PowerDVD 8, Dateiversion 2.2.0.624, dekodieren. Dabei ist die CPU-Last beim CL264dec.ax dank DxVA natürlich viel geringer, und das Deinterlacing ist auch viel besser.

Es bleibt aber ein Problem: Aufgrund der Tatsache, daß keine I- und IDR-Frames mehr im Stream vorhanden sind, kann man diese Streams mit den gängigen Programmen (h264cutter und TS Packet Editor) nicht mehr schneiden, so daß Aufnahmen von diesen Sendern im Moment relativ sinnlos sind. Erst wenn es ein Schnittprogramm gibt welches in der Lage ist, die GOPs an den zu schneidenen Stellen neu zu encoden ( wie es der Womble bei MPG2 ja auch macht ), wäre es wieder möglich einigermaßen genau zu schneiden.

Alles anzeigen

mit dem neuesten Trunk von ffmpeg funzt es wieder.

"[vdr] Possible PAFF interlaced stream bug(s) fixed in FFMPEG"

http://linuxtv.org/pipermail/vdr/2008-July/017447.html

allerdings ist bei mir die Prozessorauslastung deutlich gestiegen

Zitat

das sollte nicht nur nvidia so haben - ist auch bei ati nicht im "upstream" treiber drin (info "RGB/PAL over VGA at variable frame rate" ("sparkie" --> link)

gruß, ciax

Habe ich verfolgt. Sobald radeon meinen 780er gut genug unterstützt (Xv geht ja noch nicht) gehe ich da auch mal ran.

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

Viele Grüße,
Matthias

Hallo ihr beiden,

also bei mir ist auch seit 14 Tagen das Phänomen, dass die HD-Sender nur noch auf einer CPU laufen.

Wo liegt da jetzt das Problem genau, am ffmpeg?

Wie habt ihr die aktuelle Version gezogen?

Wie sieht es mit xinelib und xineliboutput aus, welche Versionen habt ihr da im Einsatz?

Auch bei mir ist die X-Serverlast extrem gestiegen:

Nvidia Closed-Source 173-14-05

Wäre nett wenn man ausführlichere Infos bekommt, danke vorab!

Wolfgang

Zitat

Original von wbreu
Wie sieht es mit xinelib und xineliboutput aus, welche Versionen habt ihr da im Einsatz?
Wolfgang

xinelib 1.2 und xineliboutput 1.0.1., NVidia Treiber ist 173.14.09, Kernel ist Ubuntu 2.6.24-19-generic, "UseEvents" "True" ist in xorg.conf gesetzt, Composite abgeschaltet.

Sonst fällt mir gerade nichts Relevantes ein.

Bei HD kann ich nicht mitreden, bin Kabelkunde bei Unity Media. Die haben so'n neumodischen Kram nicht im Angebot

Viele Grüße,
Matthias

Tach Team,

nachdem ich nun 2 Tage am Problem "verpixelt, ruckeln" herumgewerkelt habe, mein aktueller Stand :

Ich habe die letzten svn bzw. cvs versionen von ffmpeg und xine-lib ( sprich checkout von gestern abend ) installiert und verglichen mit einer H264 Aufnahme von Premiere vor der Encoder Umstellung auf non Iframes .

Die alte Aufnahme mit Iframes skaliert bei mir sauber auf 2 CPU's wenn auch nicht 50/50 eine läuft 100 die nächste mit biszu + 60% , Ergebniss Ruckelfrei :

http://www.abload.de/image.php?img=noiframes2rqm.jpg

Die neu Aufnahme von gestern Abend ( hier Sunshine ) skaliert nur auf eine CPU und läßt Daten aus, sprich ruckelt ( max 15 frames gefühlt ) , vereinzelt sehe ich Blockartefakte :

http://www.abload.de/image.php?img=noiframes3jhd.jpg

Testumgebung :
mkv Files die direkt aus den Streams erzeugt wurden, abgespielt im Xine, welches über vdr-xine auch meine VDR Ausgabe ist.

Nun denn, ich glaube, die Bildekodierung des neuen Encoder-Formats ist bei weiten nocht nicht angepasst, da heißt es erstmal abwarten, was die Entwicklung so bringt.

BTW, schneiden des neuen Encoder-Formats ist dank der fehlenden Iframes ein Krampf.
Das Script zum Umsetzen in mkv wird hier besprochen :
http://www.vdrportal.de/board/thread.php?threadid=73791

Grüße vom Alex

hallo an alle,

faup's analyse kann ich hier (leider) bestätigen - die artefakte sind durch ffmpeg (gestern aus dem trunk gezogen) beseitigt. allerdings skaliert "vdr-sxfe" (xinelibouput) nicht mehr 'gleichmäßig' auf beide cpu-kerne. meistens ist ein kern völlig ausgelastet - es kommt zu rucklern.

vor der providerseitigen encoderumstellung hatte der BE-2400 noch 'erträglich' ausgereicht. so ist's kein vergnügen mehr

gruß, ciax

Rincewind99

zum Thema HD bei Unitymedia versuchs mal damit:

Premiere HD;UnityDigitalTV:674000:C0M256:C:6900:513:0;514=deu,515=eng:518:1801,1831:31101:9999:311:0

Rincewind99

zum Thema HD bei Unitymedia versuchs mal damit:

Premiere HD;UnityDigitalTV:674000:C0M256:C:6900:513:0;514=deu,515=eng:518:1801,1831:31101:9999:311:0

Zitat

Original von RHS
Rincewind99

zum Thema HD bei Unitymedia versuchs mal damit:

Code

Premiere HD;UnityDigitalTV:674000:C0M256:C:6900:513:0;514=deu,515=eng:518:1801,1831:31101:9999:311:0

Senden die unverschlüsselt? Ich habe kein Premiere Abo.

Zitat

Originally posted by ciax
hallo an alle,

faup's analyse kann ich hier (leider) bestätigen - die artefakte sind durch ffmpeg (gestern aus dem trunk gezogen) beseitigt.

muss nach dem installieren vom neusten ffmpeg nochwas anderes neu kompiliert werden? hab naemlich nun ffmpeg von gestern ausm trunk, das ruckelproblem bleibt aber nach wie vor..

infinite

Zitat

Original von infinite

muss nach dem installieren vom neusten ffmpeg nochwas anderes neu kompiliert werden? hab naemlich nun ffmpeg von gestern ausm trunk, das ruckelproblem bleibt aber nach wie vor..

infinite

hi,

das zusammenspiel mit xine-lib muß meines erachtens auch gegeben sein. ich übersetze xine-lib mit "--with-external-ffmpeg=/path/to/ffmpeg-trunk-source".

also in etwa so hier bei mir:

1) in den xine-lib sources

./autogen noconfig

2) und dann in der "build umgebung"

CFLAGS='-g3 -O3 -fPIC -lm -mtune=k8 -pipe' ../xine-lib-1.2/configure --disable-debug --with-external-ffmpeg=/path/to/ffmpeg-trunk-source --disable-dxr3

reinhard nissl hat das einmal so beschrieben:
http://www.linuxtv.org/pipermail/vdr/2008-March/016195.html

falls du xineliboutput benutzt, müßtest den plug auch nochmal neu übersetzen.

gruß, ciax

EDIT: wie erwähnt, steigt die cpu-last durch den neuen providerseitigen stream beim dekodieren und sauber auf mehrere kerne wird auch nicht skaliert - aber dein athlon x2 5600 müßte schon ausreichen, daß ein core nicht voll ausgelastet ist.

wo hier noch gedreht werden kann, weiß ich leider nicht. xine/vdr-sxfe skalieren ja nicht mehr richtig ausgeglichen - eventuell müßte da was adaptiert werden (oder an ffmpeg selbst noch) ????

wieso setzt du den ffmpeg path denn auf die sourcen?

Zitat

Original von infinite
wieso setzt du den ffmpeg path denn auf die sourcen?

weil's bei mir nicht ohne angabe des pfades zu ffmpeg kompiliert hat. wenn du die "internen ffmpeg sources" die mit xine-lib kommen (??) nutzt, wird der bug-fix noch nicht dabei sein, schätze ich ... ich hab's immer mit separaten svn ffmpeg sourcen gemacht.

ciao, ciax

mh, hab jetz xinelib mit den von dir & rnissl genannten buildoptions gebaut, xineliboutput auch neu, trotzdem bleiben die ruckler.. ein core bleibt bei 100% auslastung

ich hab jetzt wohl das xinelib paket von debian-multimedia neugebaut (1.14), da ich mein debian system gerne sauber halten moechte..

da wird dann auch automatisch ein libxine-ffmpeg paket installiert?