Posts by tbshl-vdr

Quote from Lego

werde es jedoch später noch einmal richtig durchdenken

Gut so!

Also was sie machen soll: das array vergrössern wenn schon vorhanden und zu klein, und am Ende, wenn der index schon belegt ist, diesen Eintrag nach vorne verschieben, wenn da frei ist.
Letzteres ist halt speziell für diesen Fall, wo immer zwei Einträge mit gleicher Nummer kommen.
Der (erste) kaputte ist btw. vom Freitag 31. 18:15 The Office (HALLOWEEN). Da dürfte auch bei neueren Versionen kein Langtext da sein, wenn das mal jemand bestätigen könnte, bzw. überhaupt auch mit anderer SW/Receivern wär mal interessant.

Hallo,

Schuld am Absturz sind falsch gesetzte DescriptorNumber und LastDescriptorNumber im ExtendedEventDescriptor (Langtext des EPG). Wie es aussieht ist wirklich der Stream von VIVA/CC schon so kaputt, im VDR wird daran glaube ich nichts verändert.
LastDescriptorNumber ist in dem kauptten Eintrag immer 3 (müsste 15 sein), DescriptorNumber ist 1, 1, 3, 3, 5, 5 usw. (statt 0, 1, 2...)
Die betroffene Funktion ist in libsi/si.c 'void DescriptorGroup::Add(GroupDescriptor *d)'.
In neueren Versionen befindet sich dann noch:

if (length <= d->getDescriptorNumber())
      return; // see http://www.vdr-portal.de/board60-linux/board14-betriebssystem/board69-c-t-vdr/p1025777-segfault-mit-vdr-1-7-21/#post1025777

Damit wird zwar ein Absturz verhindert, das hat aber zwei Nachteile - den (sicher zu verschmerzenden) fehlenden Text im EPG, und es wird aber auch das Objekt nicht freigegeben weil es nicht im array ist (bzw. bei mehrfachen gleichen DescriptorNumbers weil überschrieben). Löschen geht hier auch nicht, da es in der aufrufenden Funktion danach noch verwendet wird.

Ich hab das deshalb mal so gemacht:

void DescriptorGroup::Add(GroupDescriptor *d) {


	//XXX VIVA/CC: kaputte DesciptorNumber/LastDescriptor


	int n = d->getDescriptorNumber();
	int l = d->getLastDescriptorNumber() + 1;
	if(array)
	{
		if(length <= n)
		{
			GroupDescriptor **a = new GroupDescriptor*[n + 1];
			int i = 0;
			for(; i < length; i++)
				a[i] = array[i];
			for(; i <= n; i++)
				a[i] = NULL;
			delete[] array;
			array = a;
			length = n + 1;
		}
	}
	if(!array)
	{
		length = l;
		array = new GroupDescriptor*[length]; //numbering is zero-based
		for(int i = 0; i < length; i++)
			array[i] = 0;
	}else
	{
		if(array[n])
		{
			if(n && !array[n - 1])
			{
				array[n - 1] = array[n];
				array[n] = NULL;
			}
			else
				n = -1;
		}
		if(length <= n)
			n = -1;
	}
	if(n >= 0)
		array[n] = d;
}

(Wobei mir gerade auffällt, dass 'if(length <= n) n = -1;' und 'if(n >= 0)' am Ende so ja überflüssig ist und ich das noch entfernen wollte)

Ich hab mich ja mal im phoronix-Forum eingeklinkt, das Problem ist jetzt auch bekannt. Jetzt kann ich da aber keine Anhänge einstellen, und weiss auch grad nicht, wo ich das mal eben ablegen könnte.
Deswegen mach ich mal nen Umweg und verweise dort auf hier und den Anhang.

Die hohen CPU-Werte sind "load average", steht auch bei "top".

Quote

Original von lola
übrigens das Speicherleck, welches ich in der 0.7.1 und .2 reproduzieren konnte, ist in der 0.7.4 weg. Mit mplayer habe ich diese Version seit einigen Tagen im Dauerlauf, absolut stabil, die geposteten CPU-Peaks waren ein Einzelfall/nicht mehr reproduzierbar.

Das ist ja gut.

Ja, mit 'xv' o.a. dürfte nix passieren. Ich hab das erst mit dem Testprogr. festgestellt - dort beim Abspielen alle paar Frames Surfaces zerstört und neu angelegt, wobei definitiv was nicht freigegeben wird.
Um sicherzugehen wollte ich das ähnlich mal im mplayer einbauen, weil eigentlich tritt das nicht auf, weil der ja jedesmal beendet wird. Dann kam die Idee, dass es mit einer Playlist gehen könnte.
Bin mir jedenfalls jetzt sehr sicher, dass da was in xvba ist, hoffentlich wird auch in nicht allzu langer Zeit was gefunden...

Quote

Original von lola
jo ist so. CPU Last bleibt auf gleichem Niveau, MEM steigt beim springen jeweils um 4% (kann also ca. 20mal umschalten )

So hängts dann vom Speicher ab, wie oft man umschalten kann. Irgendwie suboptimal
Da ja einiges auf xvba als Ursache hindeutet, hab ich mal im phoronix-Forum ein Post abgesetzt.
Hoffe man versteht mich da, aber viel und kompliziert hab ich denk ich auch nicht geschrieben...

Quote

Original von lola
vlc hat zwar mehr Systemlast durch die bidirektionale Kommunikation, gibt doch aber Hoffnung.

Ne ne, an sich funktioniert das Abspielen ja. Nur bei bei einem neuen Stream - in xine-lib Umschalten, in meinem Testprogramm simuliert oder beim mplayer durch springen in der Playlist - also wenn (ein) Surface(s) zerstört wird und neue erstellt werden, gibts Probleme. Anscheinend wird das nicht (richtig) freigegeben. Wenn ich nur ein File abspiele und das Progr. beende, kann ich das auch beliebig oft machen.

edit:

Quote

Original von lola
klappt das so bei Dir, bei ati/AMD müsste das doch mit -vo vaapi:gl übergeben werden

Das geht auch ohne 'gl'.

Hallo,

wer Zeit, Lust und xvba-HW hat, bitte mal folgendes mit mplayer-vaapi testen:
Eine Playlist erstellen mit einigen Einträgen, kann auch die selbe Datei sein. Die dann abspielen (mplayer -vo vaapi -va vaapi -fs -playlist <file>), und dabei den Speicherverbrauch beobachten.
Spezeill dann, wenn (mit "<" und ">") eine andere Datei abgespielt wird. Wahrscheinlich wird er jedesmal weiter steigen und irgendwann gar nix mehr gehen (Vorsicht, evtl. reboot nötig!).
Wenn dem so ist, dürfte der Fehler dann sehr sicher in xvba/fglrx sein.
Mit vaapi (mit ATI) für vdr sieht das dann erstmal schlecht aus, denn beim Umschalten, mindestens wenn sich die Videogrösse ändert, müssen nunmal neue Surfaces erzeugt werden.
Ganz ausschliessen kann ich natürlich nicht, dass ich einen Fehler mache und der in mplayer auch ist. Evtl. gibts ja hier auch andere Ergebnisse, wo es funktioniert.

Wer mplayer-vaapi nicht hat bzw. nicht installieren möchte, make ohne install ist ausreichend.

Quote

Original von lola
wo Probleme? im allgemeinen, also bsw. mit mplayer Stream schauen, oder speziell mit Deiner letzten Testversion?

Allgemein, ich kämpfe ja schon seit langer Zeit mit libva und xvba (wobei ich die Ursache nicht weiss, kann auch fglrx oder andere SW sein, auch HW-Probleme hatte ich ja schon in Form von defekten RAM).
Ich habe heute 0.7.4 von xvba getestet, und habe ungefähr die selben Probleme wie mit 10.8 von Catalyst (wobei da glaube ich nur HW-unterstützte Formate betroffen waren).
Momentan hab ich 10.9, also die gerade aktuelle Version im Einsatz - die funktionierte um Gegensatz zu 10.8. Nur mit der letzten xvba-Version geht nix mehr.

Quote

Original von lola
Aktueller Stand seit eben:

Catalyst 10.6
libva 0.31.1-1 sds4
xvba 0.7.4-1

Ah, OK, danke.
Habe jetzt Catalyst 10.7 getestet, und siehe da, es wird jedenfalls wieder (auf den ersten Blick richtig) wiedergegeben.
Fazit: xvba 0.7.4 geht hier nicht mit Catalyst 10.9 (10.8 eh nicht, aber da haben ja auch viele andere das Problem), aber mit 10.7 oder früher.
Interessant wären aber trotzdem nochmal Tests von anderen mit der letzten Catalyst-Version.

Das ist echt schon zum Brechen mit dem Closed-Source-Zeugs, kaum ne Chance da die Ursachen zu finden. Mit nvidia läuft es ja m.o.w. zufriedenstellend, aber hier komm ich überhaupt nicht weiter.
Problem hier ist das Umschalten, mit meiner xine-lib kommt es dabei zu segfaults (in fgrlx), mit Testprogrammen nicht, aber dafür nach einiger Zeit zu keinem Bild mehr bzw. Fehlern bei vaPutSurface.
Problem beim Umschalten ist scheinbar das Zerstören und neu erzeugen von Surfaces, mit einer Testanwendung geht das etliche Male, aber dann, und immer an der selben Stelle, kommt erst kein Bild, später gibt vaPutSurface Fehler.
Auf Fehler wie überschrieben Speicher deutet das auch nicht unbedingt hin, sonstige Defekte eigentlich auch nicht, und mit nvidia (auf einem anderen Board allerdings) gehts ja auch.

Quote

Original von Torsten73
aber auch hier kann ich das Verhalten provozieren, wenn man nskinenigmang mit aktivem rollen verwendet.

Das ist wie beim Scrollen, die OSD-Bilddaten des gesamten Bereichs werden bei jeder Änderung verarbeitet.

Quote

Original von Torsten73
ich verstehe trotzdem nicht, wieso eine hardwarebeschleunigte Anzeige eine so hohe System Last erzeugen kann. Das ist für mich unlogisch und außerdem widersprüchlich, da ja die GPU Hardwarebeschleunigung die Systemlast der CPU senkt.

Die GPU dekodiert (bzw. unterstützt dabei) aber nur diverse Formate, nicht jedes Video- bzw. Bildmaterial (ist auch Treiber-abhängig). Beim OSD ist das aber auch gar nicht der Fall, die RLE-Daten werden nur in SW in Bildpixel umgerechnet. Was die HW hier übernimmt ist nur die Skalierung.

Seit heute gibts 0.7.4 von xvba-video http://www.splitted-desktop.com/~gbeauchesne/xvba-video/
Hat das schon jemand eingesetzt bzw. kann das mal tun, und berichten ob es Probleme gibt (bitte Catalyst-Version dazuschreiben)?

Quote

Original von Torsten73
von einer Hardware beschleunigten Rendermethode kann hier also nicht wirklich die Rede sein, oder heißt Hardware bzw. X11 nicht, dass die Grafikkarte zum darstellen / Rendern des OSD genutzt wird?

Doch, ist schon so. Es wird aber immer der gesamte Bereich, in dem sich etwas ändert (hier praktisch der gesamte Bereich, nur der Teil für die Farbtasten ist glaube ich extra) kopiert und berechnet, das kostet halt.
Besser wäre, wenn nur der sich witklich ändernde Bereich übertragen würde, also der Balken.

Ich denke aber, bei FullHD hätte ich hier auch das Problem, mit 1360 geht es, wird aber schon eng.

Speicher, Bustakt etc. könnte man noch ein Auge drauf werfen.
Geringfügig Verbesserung kann auch bringen, den video_out-Teil von xine-lib mit höherer Optimierung zu übersetzen.

Quote

Original von Torsten73
- in den Einstellungen Plugin xineliboutput Belding Methode: Hardware -> Sehr schöne OSD Schrift (egal welcher Skin) aber System verarbeitet nur rund 1-2 Bilder / Sekunde beim scrollen im OSD, genauso lahm wie die FB

Keine Lösung, nur als Hinweis (Zeit zum hier einmischen hab ich leider auch nicht viel):

Die Last beim Scrollen ist hoch, weil jedesmal bei Änderung die kompletten OSD-Bilddaten übertragen werden und evtl. auch (Transparenz) bearbeitet werden.
An sich sollte das aber keine solchen Probleme geben,. Full-HD hab ich nicht, mit dem Atom-Board (230) gibts beim (dauerhaften) scrollen schon mal Aussetzter, aber nicht so extrem wie 1-2 Bilder/sec.

Wie ist denn die Last ohne und mit OSD (beim scrollen)?

Danke, ist also tatsächlich ein fglrx-Problem.
Gut, weil ich dann deswegen nicht nach Fehlern von mir suchen muss

Hallo,

ich hab das ja prinzipiell am laufen, mit nvidia auch ganz gut. Was mich hier aufhält ist, dass es mit ATI nicht auch so läuft. Bei SW-Dekodierung gibts ein Problem, wo ich noch absolut nicht weiss, woran das liegt. Beim Suchen danach hab ich mal den letzten fglrx installiert (10.8 ). Da etliches am Source geändert, wollte ich vorhin nochmal HW-Dekodierung testen, und es ging so gut wie gar nix.
Nachdem auch mplayer das selbe zeigte, hab ich wieder 10.7 installiert - und nun gehts auch wieder...
Hab noch nicht gesucht - ist das nur bei mir so oder gibts da was dazu?

Gruss,
Thomas

Sorry, ist Quatsch mit dem Pfad. Bei Dir kommt es ja gar nicht soweit, hab ich wohl aus einem Zitat rausgelesen.
Evtl. falsche Version (32/64 bit, oder auch nicht passend libva <-> xvba) installiert?

edit:
Version hast Du ja geschrieben, sollte passen. Aber evtl. 32/64bit falsch.

Sieh mal, ob es "/usr/lib/va/drivers/fglrx_drv_video.so" bei Dir gibt, bzw. ist das ein Link auf "xvba_drv_video.so".

Quote

Original von wbreu
nur nicht aufgeben...

nene, das wär das letzte

Quote

Original von wbreuFalls du Ram benötigst, melde dich habe ich noch mehr als genug in der Bastelkiste liegen.

Ich hab mal die Riegel neu gesteckt, Test läuft noch aber schon erheblich länger als vorher, scheint also erstmal behoben. Wenns nochmal auftritt wars wahrscheinlich doch nicht nur ein Kontaktproblem und ein Riegel wird doch einen weg haben. In dem Fall werd ich sicher darauf zurückkommen.

Hallo,

ja, sorry, kam lange nix von mir.
Git einrichten wäre sicher nicht verkehrt, ich denk ja immer wieder, noch ein paar Tage und ich kann mal was bereitstellen. Aber denkste...
Die letzten Tage hab ich mit Fehlersuche zu einem Problem verbracht - sporadisch wurde gemeldet, dass Picture-IDs (fürs OSD) ungültig seien u.ä.
Ursache war (bzw. ist, hab das jetzt mit Locks verhindert) video-vdpau, das fordert Buffer an aus einem Pool, der auch für Pictures verwendet wird. Zum rendern holt es also solche Buffer und merkt sich die IDs, die werden aber wieder freigegeben, bei EndPicture allerdings ruft es nochmal ein destroy mit diesen IDs auf. Das ist erstmal nicht so schlimm, da die Buffer-Verwaltung weiss, dass die IDs schon freigegeben sind. Wenn es jetzt aber passierte, dass zwischen diesen Zeitpunkten ein Picture angefordert wurde, waren für die Buffer-Verw. die IDs schon frei, das Picture bekam eine solche, nur wenn dann EndPicture destroy aufruft, ist die ID für die Verw. ja benutzt und wird also freigegeben... grrr...
Nur gut, dass der vdpau-Teil als Source da ist, sonst hätt ich evtl. noch ewig gesucht...

Momentan kämpfe ich mit dem ATI-Rechner, da lief irgendwie einiges sehr seltsam. Debuggen ist kaum möglich, da z.B. wenn vdr-sxfe sich nicht sauber beendet hat und ich es wieder laufen liess, gab es erstmal einen Soft-Lock im Kernel, nach 2min reagiert der Rechner zwar wieder, aber den Prozess kriegt man nicht mehr weg -> reboot.
Als jetzt aber beim Kernelbauen sporadisch an verschiedenen Stellen der Compiler abstürtzte, hab ich mal einen memtest laufen lassen und siehe da, der Speicher hat auch was weg. Naja, hoffe, dass dann wenigsten diese Probleme (reboot nötig) mit funktionierendem Speicher weg sind.

Naja, irgendwas in der Art ist immer, das bremst zusätzlich. Wobei der Stand jetzt eigentlich recht weit ist, jdfls. ausgehend von dem, wie es mit vdpau läuft.

Gruss,
Thomas

Quote

Original von Atechsystem
Bei xine (ui) kann man leider nicht einfach die Pfeiltasten und div. Buchstaben etc. drücken um zu Navigieren.

Das war glaube ich auch das Problem, als ich das vor langer Zeit mal getestet habe. Wobei ich meine, dass das dann mit Anpassungen (keymap etc.) doch ging.
Jedenfalls geht xine-ui jetzt auch auf einem Rechner, aber nur mit FB, was das Ergebnis evtl. verfälscht - dazu gleich mehr.
Ich habe mit vdr 1.7.11 und 1.7.15 getestet, mit und ohne xine-lib-Patch, das Ergebnis ist gleich, mit 720p ist es bei schnellem Vorlauf so, dass die Bilder in falscher Reihenfolge angezeigt werden, aber es ist *nicht* so, dass überhaupt oder bei Umschalten auf normale Geschwindigkeit wieder auf die Anfangsposition gesprungen wird. Dafür muss ich xine-ui nach dem Beenden einer Aufnahme neu starten, da geht sonst erstmal nix mehr.
vdr kann ich auf dem vdpau-Test-Rechner momentan nicht ohne (eigene) Anpassungen verwenden, da ich sonst keine FB habe (geht seriell von einer Schaltung aus mit eigenem Protokoll), und ohne die kann ich vdr über xine-ui momentan nicht steuern, deswegen evtl. "falsche" Testergebnisse, wobei ich davon ausgehe, dass meine Patches auf die Aufnahme-Wiedergabe keinen Einfluss haben, aber ausschliessen kann ich es auch nicht...
Ich bleib auf jeden Fall dran, aber wenig Zeit, und Priorität liegt momentan bei libva...

Ach so, die Ausgabe auf Konsole wird erst mit --verbose gesprächig, evtl. gibts ja doch Hinweise. Und Tests mit/ohne Patch wäre auch hilfreich (wenn ich das überlesen habe, sorry).

Gruss,
Thomas

edit:
fehlerhafte index-Datei dürfte nicht in Frage kommen, die habe ich auch gelöscht -> keine Änderung.