Probleme mit SuSE 9.0 und KDE 3.1.4
Hallo Liste! Ich habe vorgestern SuSE-Linux 9.0 Prof komplett neu aufgespielt. Soweit läuft auch alles ganz gut. Allerdings haben sich folgende zwei Probleme ergeben: 1. .avi-Kurzfilme, welche ich mit meiner Digitalkamera aufgenommen habe und unter 8.1 problemlos liefen, zeigen jetzt nur noch ein schwarzes Bild, wobei der Ton aber zu hören ist. 2. Werden Menü-Einträge im K-Menü nicht mehr automatisch aktualisiert? Beispielsweise ist auf meinem System wine installiert. Es ist aber nirgends ein Eintrag zu finden. Früher konnte man zwischen SuSE- und KDE-Menü wählen oder auch das SuSE-Work-Menü einfügen. Diese Punkte kann ich im Kontrollzentrum nicht finden. Gibt es sie nicht mehr? Gruß Dirk
Am Donnerstag, 16. Oktober 2003 13:42 schrieb Dirk Albrecht:
1. .avi-Kurzfilme, welche ich mit meiner Digitalkamera aufgenommen habe und unter 8.1 problemlos liefen, zeigen jetzt nur noch ein schwarzes Bild, wobei der Ton aber zu hören ist.
Mit was spielst Du die ab? MPlayer und xine (sowie darauf aufbauende UIs wie kaffeine, kmplayer, kaboodle, ...) sind bei SuSE ja standardmässig ziemlich beschnitten. Von MPlayer gibts bei Packman ne SuSE 9.0er Version und die xine Variante für SuSE 8.2 tuts (wie mir inzwischen mehrfach bestätigt wurde) auch problemlos unter 9.0. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Donnerstag, 16. Oktober 2003 21:47 schrieb Manfred Tremmel:
Version und die xine Variante für SuSE 8.2 tuts (wie mir inzwischen mehrfach bestätigt wurde) auch problemlos unter 9.0.
Mit libxine1-XYZ-1_rc1-0.pm.0.i686.rpm 8.2-Paketen von Packman gabe es keine Konflikte, die nicht mit Packman oder 9.0 Paketen zu lösen wären. (Die Plugins für esd und dvb habe ich nicht installiert) libxine funktioniert bei mir nun mit kaffeine und xine-ui von Suse und xina-ui-aa von von Packman. Nur mit xine-ui von Packman ging es nicht so glatt: linux: rpm -Uvh xine-ui-0.9.22-0.pm.0.i686.rpm Fehler: Failed dependencies: libcrypto.so.0.9.6 is needed by xine-ui-0.9.22-0.pm.0 libssl.so.0.9.6 is needed by xine-ui-0.9.22-0.pm.0 linux: rpm -ql openssl |grep lib /usr/lib/libcrypto.so.0.9.7 /usr/lib/libssl.so.0.9.7 An xine-ui von Suse stört mich nur, daß das Cloudy-Skin nicht dabei ist und der Spruch über die eingeschränkte Version. Außerdem reagiert das Video-Fenster beim Verschieben/Zoomen ein bisschen träger als bei 8.2/Packman. Das kann aber eigentlich nicht an xine-ui liegen oder? Kann Selbstkompilieren der Pakete eigentlich irgendwelche Geschwindigkeitsvorteile bringen? Werde jetzt mal DVD:Rip + transcode bei mir testen. ciao, Rüdiger
Hallo, Am Thu, 16 Oct 2003, Rüdiger Meier schrieb:
Am Donnerstag, 16. Oktober 2003 21:47 schrieb Manfred Tremmel:
Version und die xine Variante für SuSE 8.2 tuts (wie mir inzwischen mehrfach bestätigt wurde) auch problemlos unter 9.0.
Mit libxine1-XYZ-1_rc1-0.pm.0.i686.rpm 8.2-Paketen von Packman gabe es keine Konflikte, die nicht mit Packman oder 9.0 Paketen zu lösen wären. (Die Plugins für esd und dvb habe ich nicht installiert)
libxine funktioniert bei mir nun mit kaffeine und xine-ui von Suse und xina-ui-aa von von Packman.
Nur mit xine-ui von Packman ging es nicht so glatt:
linux: rpm -Uvh xine-ui-0.9.22-0.pm.0.i686.rpm Fehler: Failed dependencies: libcrypto.so.0.9.6 is needed by xine-ui-0.9.22-0.pm.0 libssl.so.0.9.6 is needed by xine-ui-0.9.22-0.pm.0
linux: rpm -ql openssl |grep lib /usr/lib/libcrypto.so.0.9.7 /usr/lib/libssl.so.0.9.7
Oeh, ja, dat is normal. Das ist das "autoreqprov" von RPM. xine-ui verwendet offenbar irgendwas aus libcrypto/libssl, und da werden dann eben die Abhaengigkeiten eingetragen... Hm. Wer erstellt denn die xine-RPMs bei packman? Evtl. koennte man da mal diese Abhaengigkeiten "per Hand" definieren... Bzw. ganz weglassen (ich weiss nicht, wozu xine die libcrypto/libssl braucht).
An xine-ui von Suse stört mich nur, daß das Cloudy-Skin nicht dabei ist und der Spruch über die eingeschränkte Version.
Sonst hast du keine Probleme, oder?
Außerdem reagiert das Video-Fenster beim Verschieben/Zoomen ein bisschen träger als bei 8.2/Packman. Das kann aber eigentlich nicht an xine-ui liegen oder?
Theoretisch durchaus. Welches Toolkit verwendet xine?
Kann Selbstkompilieren der Pakete eigentlich irgendwelche Geschwindigkeitsvorteile bringen?
Eindeutig ja. Denn dann kann xine 3dnow, sse, sse2, mmx und sonstwas verwenden (wobei das eher die "untergelagerten" libs betrifft). Generell gilt (auch unter Windows, nur dass man's da nicht kann ;) dass man in diesem Bereich (video) am besten selbst kompiliert. Und da ist ein "passendes" und nicht "kastriertes" src.rpm von packman mehr wert, als ein binary-rpm. -dnh -- Wenn man Signaturen essen könnte, hätten in Dag° alle durch mich Gewichtsprobleme. [WoKo in dag°]
Am Sonntag, 19. Oktober 2003 04:53 schrieb David Haller:
Am Thu, 16 Oct 2003, Rüdiger Meier schrieb:
linux: rpm -ql openssl |grep lib /usr/lib/libcrypto.so.0.9.7 /usr/lib/libssl.so.0.9.7
Oeh, ja, dat is normal. Das ist das "autoreqprov" von RPM. xine-ui verwendet offenbar irgendwas aus libcrypto/libssl, und da werden dann eben die Abhaengigkeiten eingetragen...
Jo.
Hm. Wer erstellt denn die xine-RPMs bei packman? Evtl. koennte man da
Meinereiner.
mal diese Abhaengigkeiten "per Hand" definieren... Bzw. ganz weglassen (ich weiss nicht, wozu xine die libcrypto/libssl braucht).
Für https Übertragungen zum Bleistift. Wenn ich das richtig im Kopf habe, liegt es an der libcurl, die wiederum verwendet wird, um unterschiedliche skins runterzuladen. Die eigentlichen Übertragungen von Videostreams macht ja die libxine, bzw. deren plugins. So gesehen denke ich, es wäre keine Katastrophe da mal mit --nodeps zu installieren (falls mich jemand darauf anspricht, ich leugne, das jemals gesagt zu haben). Ein 'Autoreqprov: off' ist halt so ne Sache, wenn sich was ändert, kriegt man es kaum mit und bei irgend jemanden läufts dann nicht ...
Eindeutig ja. Denn dann kann xine 3dnow, sse, sse2, mmx und sonstwas verwenden (wobei das eher die "untergelagerten" libs betrifft).
Tut es, wird aber immer mitcompiliert (sind alles Assembler-Routinen) und beim ersten Start geprüft, was am schnellsten läuft (die Werte kann man beim Start auf der Konsole mitlesen), selbst compilieren bringt in dem Bereich normalerweise nicht.
Generell gilt (auch unter Windows, nur dass man's da nicht kann ;) dass man in diesem Bereich (video) am besten selbst kompiliert. Und da ist ein "passendes" und nicht "kastriertes" src.rpm von packman mehr wert, als ein binary-rpm.
Naja, ehrlich gesagt glaube ich, dass die wenigsten User in der Lage sind, da erkennbar mehr rauszuholen. Wer glaubt mit nem simplen 'rpm --rebuild' irgend einen Vorbild rauszuholen (auch mit --target), der irrt. Wer natürlich absolute Ahnung vom gcc, seinen Optimierungen hat und die /usr/lib/rpm/rpmrc entsprechend aufgerüstet hat, mag in der Lage sein, noch 1 oder 2 Prozent rauszuschinden. Aber genau die Prozessoren, die die entsprechenden Möglichkeiten bieten, die haben den minimalen Schub nicht nötig. Glaub mir, ich hab da schon einige Diskussionen auf der xine-developer Liste hinter mir, da gibts einige entwickler, die das für kompletten Schwachsinn halten, überhaupt CFLAGS mitzugeben, da xine im Makefile für die entsprechenden Bereiche lange ausgetüftelte und -getestete Optimierungsparameter enthält. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Hallo, Am Sun, 19 Oct 2003, Manfred Tremmel schrieb:
Am Sonntag, 19. Oktober 2003 04:53 schrieb David Haller:
Am Thu, 16 Oct 2003, Rüdiger Meier schrieb:
linux: rpm -ql openssl |grep lib /usr/lib/libcrypto.so.0.9.7 /usr/lib/libssl.so.0.9.7
Oeh, ja, dat is normal. Das ist das "autoreqprov" von RPM. xine-ui verwendet offenbar irgendwas aus libcrypto/libssl, und da werden dann eben die Abhaengigkeiten eingetragen...
Jo.
Hm. Wer erstellt denn die xine-RPMs bei packman? Evtl. koennte man da
Meinereiner.
*g*
mal diese Abhaengigkeiten "per Hand" definieren... Bzw. ganz weglassen (ich weiss nicht, wozu xine die libcrypto/libssl braucht).
Für https Übertragungen zum Bleistift. Wenn ich das richtig im Kopf habe, liegt es an der libcurl, die wiederum verwendet wird, um unterschiedliche skins runterzuladen.
Ah.
Die eigentlichen Übertragungen von Videostreams macht ja die libxine, bzw. deren plugins. So gesehen denke ich, es wäre keine Katastrophe da mal mit --nodeps zu installieren (falls mich jemand darauf anspricht, ich leugne, das jemals gesagt zu haben).
Ein 'Autoreqprov: off' ist halt so ne Sache, wenn sich was ändert, kriegt man es kaum mit und bei irgend jemanden läufts dann nicht ...
Ack. Es gibt halt leider wohl keinen Weg, eine automatisch generierte Abhaengigkeit wieder rauszunehmen... Man koennte aber evtl. ein Makro definieren, dass die Abhaengigkeiten generiert und ausgibt... %define my_deps %(find $RPM_BUILD_ROOT -type f | \ /usr/lib/rpm/find-requires | grep -v 'libcrypto\|libssl' ) %define my_provides %(find $RPM_BUILD_ROOT -type f | /usr/lib/rpm/find-provides ) Requires: %{my_deps} Provides: %{my_provides} Autoreqprov: off Oder so aehnlich... Dummerweise braucht man da halt schon nen binary samt den libs... Und ob das funktioniert? Naja, je nachdem, wie du xine baeckst waere das sogar nen Test wert ;)
Eindeutig ja. Denn dann kann xine 3dnow, sse, sse2, mmx und sonstwas verwenden (wobei das eher die "untergelagerten" libs betrifft).
Tut es, wird aber immer mitcompiliert (sind alles Assembler-Routinen) und beim ersten Start geprüft, was am schnellsten läuft (die Werte kann man beim Start auf der Konsole mitlesen), selbst compilieren bringt in dem Bereich normalerweise nicht.
Achso. Jo, dann bringt ein selber kompilieren natuerlich nicht mehr. Hab ich das evtl. mit mplayer verwechselt, wo "normal" nicht die optimierten MMX/SSE/3dnow Assemblersachen einkompiliert werden? Oder war das irgendwas anderes... Apropos: weisst du was von nem Port der Sourcen von encore/src/intel_mmx/*.c von M$-inline MASM zu nasm/gas/gcc-inline-gas?
Generell gilt (auch unter Windows, nur dass man's da nicht kann ;) dass man in diesem Bereich (video) am besten selbst kompiliert. Und da ist ein "passendes" und nicht "kastriertes" src.rpm von packman mehr wert, als ein binary-rpm.
Naja, ehrlich gesagt glaube ich, dass die wenigsten User in der Lage sind, da erkennbar mehr rauszuholen. Wer glaubt mit nem simplen 'rpm --rebuild' irgend einen Vorbild rauszuholen (auch mit --target), der irrt.
Kommt auf das Paket an, bei xine offenbar nicht, s.o. :)
Wer natürlich absolute Ahnung vom gcc, seinen Optimierungen hat und die /usr/lib/rpm/rpmrc entsprechend aufgerüstet hat, mag in der Lage sein, noch 1 oder 2 Prozent rauszuschinden.
*lol* $ sh -x ~/bin/rpmbc x2divx.spec [..] + rpm -bc --target=athlon x2divx.spec + tee x2divx.spec.log Building target platforms: athlon Building for target athlon [..] $ grep athlon /etc/rpmrc optflags: athlon -O2 -march=athlon -mcpu=athlon -malign-functions=4 -fschedule-insns2 -mwide-multiply arch_canon: athlon: athlon 1 buildarchtranslate: athlon: i386 arch_compat: athlon: i686 arch_compat: i686: athlon i686 i586 buildarch_compat: athlon: i686 buildarch_compat: i686: athlon $ gcc --version pgcc-2.95.3 (das ist ein gcc-2.95.2 mit pgcc-patch + Athlon-patch -- und nein, ich hab nicht allzuviel Ahnung vom gcc ;)) *SCNR*
Aber genau die Prozessoren, die die entsprechenden Möglichkeiten bieten, die haben den minimalen Schub nicht nötig. Glaub mir, ich hab da schon einige Diskussionen auf der xine-developer Liste hinter mir, da gibts einige entwickler, die das für kompletten Schwachsinn halten, überhaupt CFLAGS mitzugeben, da xine im Makefile für die entsprechenden Bereiche lange ausgetüftelte und -getestete Optimierungsparameter enthält.
Bei mir hat das schon einiges gebracht und bringt auch einiges, v.a. wenn der Athlon vom Makefile nicht als i686 erkannt wird, und dann mit -march=i386 kompiliert wird usw... Und bei meinem Athlon 500 bringt das Optimieren fuer mmx/3dnow durchaus was (ein Film ruckelt, oder eben nicht ;). -dnh -- [OE] Zusätzlich muß man auf automatischen Zeilenumbruch sowie automatisch eingefügte Signaturen verzichten und bei Antworten auf qp-codierte Artikel das Quoting manuell nachbearbeiten. Da kann man seine Artikel auch gleich per telnet localhost 119 einliefern. [Marc Haber in dcsn]
Am Sonntag, 19. Oktober 2003 23:54 schrieb David Haller:
Ack. Es gibt halt leider wohl keinen Weg, eine automatisch generierte Abhaengigkeit wieder rauszunehmen...
Nö, leider nicht, wenn man einzelne Ausschliesen könnte, wäre das nicht übel. Gerade mit der neuen libxine (momentan noch cvs, release letztes Wochenende wurde wieder mal verschoben), da gibts jetzt dann das xvmc Plugin, das ne Abhängigkeit zur libXvMCNVIDIA_dynamic.so.1 hat. Dieses schöne Teil stammt vom NVidia Treiber, der ja bekanntermassen nicht mehr per RPM installiert wird, womit man so ne Abhängigkeit nie los wird (ich hasse sowas).
Man koennte aber evtl. ein Makro definieren, dass die Abhaengigkeiten generiert und ausgibt...
%define my_deps %(find $RPM_BUILD_ROOT -type f | \ /usr/lib/rpm/find-requires | grep -v 'libcrypto\|libssl' ) %define my_provides %(find $RPM_BUILD_ROOT -type f | /usr/lib/rpm/find-provides )
Requires: %{my_deps} Provides: %{my_provides} Autoreqprov: off
Wäre ne Idee, ich muß mir das nächstes Wochenend mal genauer durch den Schädel rammen. Unter der Woche (schei* SAP Umstellung) ist die Zeit zu kurz und der Kopf zu dicht.
Oder so aehnlich... Dummerweise braucht man da halt schon nen binary samt den libs... Und ob das funktioniert?
Naja, je nachdem, wie du xine baeckst waere das sogar nen Test wert ;)
Ich hab meinen täglichen CVS-Build, da wäre immer ein taufrisches binary parat, daran sollte es nicht scheitern. Mal schaun.
Achso. Jo, dann bringt ein selber kompilieren natuerlich nicht mehr.
Nö.
Hab ich das evtl. mit mplayer verwechselt, wo "normal" nicht die optimierten MMX/SSE/3dnow Assemblersachen einkompiliert werden? Oder war das irgendwas anderes...
Soweit ich weiß, beherrscht MPlayer doch auch beide Varianten, entweder beim compile festlegen, oder zur Laufzeit. Bin aber da nicht so dicht drin, Henne ist bei Packman der MPlayer bastler.
Apropos: weisst du was von nem Port der Sourcen von encore/src/intel_mmx/*.c von M$-inline MASM zu nasm/gas/gcc-inline-gas?
Sorry, nein.
Kommt auf das Paket an, bei xine offenbar nicht, s.o. :)
Ja, differiert natürlich je nachdem.
Bei mir hat das schon einiges gebracht und bringt auch einiges, v.a. wenn der Athlon vom Makefile nicht als i686 erkannt wird, und dann mit -march=i386 kompiliert wird usw... Und bei meinem Athlon 500 bringt das Optimieren fuer mmx/3dnow durchaus was (ein Film ruckelt, oder eben nicht ;).
Naja, mit xine meine CPU (Celeron 1 GHz) auf über 30% Auslastung zu bringen ist hier nur noch mit hochbitratigen DVD-Szenen möglich, die üblichen DivX Dinger bleiben im einstelligen Bereich. Da noch ein bisserl rauszukitzeln ist ganz lustig (meine täglichen CVS-Builds sind ja auch mit allem PiPaPo compiliert und laufen z.B. auf nem PII oder Athlon < XP gar nicht mehr), in der Praxis ist es aber irrelevant. Naja, spielerei eben. Wenn ich jetzt noch ne GeForce >= 4 reinpressen würde und den xvmc Treiber nutzen würde, könnte ich die CPU schlafen schicken ;-) -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Hallo, Am Mon, 20 Oct 2003, Manfred Tremmel schrieb:
Am Sonntag, 19. Oktober 2003 23:54 schrieb David Haller:
Ack. Es gibt halt leider wohl keinen Weg, eine automatisch generierte Abhaengigkeit wieder rauszunehmen...
Nö, leider nicht, wenn man einzelne Ausschliesen könnte, wäre das nicht übel. Gerade mit der neuen libxine (momentan noch cvs, release letztes Wochenende wurde wieder mal verschoben), da gibts jetzt dann das xvmc Plugin, das ne Abhängigkeit zur libXvMCNVIDIA_dynamic.so.1 hat. Dieses schöne Teil stammt vom NVidia Treiber, der ja bekanntermassen nicht mehr per RPM installiert wird, womit man so ne Abhängigkeit nie los wird (ich hasse sowas).
ACK. *ARGL*
Man koennte aber evtl. ein Makro definieren, dass die Abhaengigkeiten generiert und ausgibt...
%define my_deps %(find $RPM_BUILD_ROOT -type f | \ /usr/lib/rpm/find-requires | grep -v 'libcrypto\|libssl' ) %define my_provides %(find $RPM_BUILD_ROOT -type f | /usr/lib/rpm/find-provides )
Requires: %{my_deps} Provides: %{my_provides} Autoreqprov: off
Wäre ne Idee, ich muß mir das nächstes Wochenend mal genauer durch den Schädel rammen. Unter der Woche (schei* SAP Umstellung) ist die Zeit zu kurz und der Kopf zu dicht.
*g*
Oder so aehnlich... Dummerweise braucht man da halt schon nen binary samt den libs... Und ob das funktioniert?
Naja, je nachdem, wie du xine baeckst waere das sogar nen Test wert ;)
Ich hab meinen täglichen CVS-Build, da wäre immer ein taufrisches binary parat, daran sollte es nicht scheitern. Mal schaun.
Oh, dann koennte das in dem Falls sogar fast praktikabel sein ;)
Hab ich das evtl. mit mplayer verwechselt, wo "normal" nicht die optimierten MMX/SSE/3dnow Assemblersachen einkompiliert werden? Oder war das irgendwas anderes...
Soweit ich weiß, beherrscht MPlayer doch auch beide Varianten, entweder beim compile festlegen, oder zur Laufzeit. Bin aber da nicht so dicht drin, Henne ist bei Packman der MPlayer bastler.
Stimmt glaube ich -- ich hatte nur schonmal die Situation, wo ich heftig tricksen musste, bis dann die richtigen ASM-Sachen verwendet wurden ;)
Apropos: weisst du was von nem Port der Sourcen von encore/src/intel_mmx/*.c von M$-inline MASM zu nasm/gas/gcc-inline-gas?
Sorry, nein.
Schade, ich hab da mal angefangen (in NASM), aber das als PIC Code zu machen, daran scheitere ich IIRC... [..]
Bei mir hat das schon einiges gebracht und bringt auch einiges, v.a. wenn der Athlon vom Makefile nicht als i686 erkannt wird, und dann mit -march=i386 kompiliert wird usw... Und bei meinem Athlon 500 bringt das Optimieren fuer mmx/3dnow durchaus was (ein Film ruckelt, oder eben nicht ;).
Naja, mit xine meine CPU (Celeron 1 GHz) auf über 30% Auslastung zu bringen ist hier nur noch mit hochbitratigen DVD-Szenen möglich, die üblichen DivX Dinger bleiben im einstelligen Bereich. Da noch ein bisserl rauszukitzeln ist ganz lustig (meine täglichen CVS-Builds sind ja auch mit allem PiPaPo compiliert und laufen z.B. auf nem PII oder Athlon < XP gar nicht mehr), in der Praxis ist es aber irrelevant. Naja, spielerei eben. Wenn ich jetzt noch ne GeForce >= 4 reinpressen würde und den xvmc Treiber nutzen würde, könnte ich die CPU schlafen schicken ;-)
*g* Naja, meine Mystique hat eben auch keine 3D HW-Beschleunigung, da haengt alles dann an der CPU... Ich merk die CPU-Belastung deutlich... Und wenn ich da das dekodieren effektiver machen kann macht sich das bei mir sofort in der Bildqualitaet / Framerate bemerkbar. Klar, sowas kann man mit entsprechend mehr WUMMS in der CPU und/oder GraKa auch erschlagen... Ich haenge aber immer noch an dem Gedanke, dass man nicht sinnlos CPU-Power verbraet, sondern das vorhandene ausnuetzt... Beim Mitschneiden (mit xawtv) muss ich schon an den Einstellungen drehen, damit das ohne Framedrops laeuft... Ja, ich weiss, dass meine CPU fuer sowas eigentlich zu schwach ist, aber es geht ja, wenn man die CPU richtig ausnutzt :) Klar, mit ner GeForce blablubb-ganzwastolles und nem Intel Pentium 4 groesser 3 GHz, da laeuft sowas ganz ohne Optimierungen... -dnh -- Windows verhält sich zu Betriebssystemen wie Astrologie zu Astronomie. -- am DLUG-Stammtisch
Am Dienstag, 21. Oktober 2003 00:35 schrieb David Haller:
Am Mon, 20 Oct 2003, Manfred Tremmel schrieb:
Nö, leider nicht, wenn man einzelne Ausschliesen könnte, wäre das nicht übel. Gerade mit der neuen libxine (momentan noch cvs, release letztes Wochenende wurde wieder mal verschoben), da gibts jetzt dann das xvmc Plugin, das ne Abhängigkeit zur libXvMCNVIDIA_dynamic.so.1 hat. Dieses schöne Teil stammt vom NVidia Treiber, der ja bekanntermassen nicht mehr per RPM installiert wird, womit man so ne Abhängigkeit nie los wird (ich hasse sowas).
ACK. *ARGL*
Naja, ich hab mal rumprobiert, die automatischen Abhängigkeiten lassen sich für das einzelne Subpacket abklemmen, dann gehts schon.
Requires: %{my_deps} Provides: %{my_provides} Autoreqprov: off
Wäre ne Idee, ich muß mir das nächstes Wochenend mal genauer durch den Schädel rammen. Unter der Woche (schei* SAP Umstellung) ist die Zeit zu kurz und der Kopf zu dicht.
*g*
Im täglichen cvs build hab ich auf jeden Fall mal Autoreqprov: off reingestellt und die eh schon vorhandenen händisch eingefügten Abhängigkeiten als einzige basis genommen. Wer es unter SuSE 9.0 mal ausprobieren will, wie immer unter: ftp://packman.iu-bremen.de/testing/xine-cvs (ja, hab kxine rausgenommen, seit Monaten hat sich da nix mehr bewegt, kaffeine kommt rein, sobald der cvs-Download wirklich funktioniert, xine-vcdx fliegt auch in kürze, da in libxine integriert).
Ich hab meinen täglichen CVS-Build, da wäre immer ein taufrisches binary parat, daran sollte es nicht scheitern. Mal schaun.
Oh, dann koennte das in dem Falls sogar fast praktikabel sein ;)
Jo, prinzipiell schon. Das spec-File wird auch dynamisch generiert, also wieso nicht.
Schade, ich hab da mal angefangen (in NASM), aber das als PIC Code zu machen, daran scheitere ich IIRC...
Hehe, hab mich seit Amiga-Zeiten nicht mehr mit Assembler rumgeschlagen.
*g* Naja, meine Mystique hat eben auch keine 3D HW-Beschleunigung, da haengt alles dann an der CPU... Ich merk die CPU-Belastung deutlich... Und wenn ich da das dekodieren effektiver machen kann macht sich das bei mir sofort in der Bildqualitaet / Framerate bemerkbar. Klar, sowas kann man mit entsprechend mehr WUMMS in der CPU und/oder GraKa auch erschlagen...
Ich haenge aber immer noch an dem Gedanke, dass man nicht sinnlos CPU-Power verbraet, sondern das vorhandene ausnuetzt...
Dreimal darfst Du raten, warm ich die SuSE 8.2 auf PPC portiere und weiterhin auf meinem PowerBook mit 266 MHz arbeite. Die Kiste ist im Prinzip für das was ich mache flott genug und die glibc 2.3.2 mit gcc 3.3.1 hat KDE auf ne angenehme Performance gehieft.
Beim Mitschneiden (mit xawtv) muss ich schon an den Einstellungen drehen, damit das ohne Framedrops laeuft... Ja, ich weiss, dass meine CPU fuer sowas eigentlich zu schwach ist, aber es geht ja, wenn man die CPU richtig ausnutzt :)
Glaub ich Dir gern.
Klar, mit ner GeForce blablubb-ganzwastolles und nem Intel Pentium 4 groesser 3 GHz, da laeuft sowas ganz ohne Optimierungen...
Ist aber auch langweilig. Ich find Computergrafik auch nicht mehr so spannend wie früher, wenn man mit wenigen Farben tricksen musste um noch was vernünftiges rauszuholen (die 640x512 Bildpunkte mit 16 Farben war mein Liblingsmodus auf dem Amiga und meine ersten Animationen hab ich mit 3 MB Ram, 7,14 MHz und dieser Auflösung auch ruckelfrei hingekriegt). -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Donnerstag, 16. Oktober 2003 21:47 schrieb Manfred Tremmel:
Mit was spielst Du die ab? MPlayer und xine (sowie darauf aufbauende UIs wie kaffeine, kmplayer, kaboodle, ...) sind bei SuSE ja standardmässig ziemlich beschnitten. Von MPlayer gibts bei Packman ne SuSE 9.0er Version und die xine Variante für SuSE
Wo soll die exakt sein? Ich habe eben noch einmal geschaut, nein es ist die 8.2er Version, die wegen libssl nicht will wie sie soll. Kein Problem, die Sourcen von Packmann installiert und neu übersetzt funktionieren wunschgemäß.
8.2 tuts (wie mir inzwischen mehrfach bestätigt wurde) auch problemlos unter 9.0.
Keine Ahnung von xine, ich wüste nicht einmal, was ich zu installieren hätte, die Auswahl ist groß. Robert
Am Donnerstag, 16. Oktober 2003 23:07 schrieb Hans-Robert Wagner:
Am Donnerstag, 16. Oktober 2003 21:47 schrieb Manfred Tremmel:
Mit was spielst Du die ab? MPlayer und xine (sowie darauf aufbauende UIs wie kaffeine, kmplayer, kaboodle, ...) sind bei SuSE ja standardmässig ziemlich beschnitten. Von MPlayer gibts bei Packman ne SuSE 9.0er Version und die xine Variante für SuSE
Wo soll die exakt sein? Ich habe eben noch einmal geschaut, nein es
ftp://packman.iu-bremen.de/testing/9.0
Keine Ahnung von xine, ich wüste nicht einmal, was ich zu installieren hätte, die Auswahl ist groß.
libxine und xine-ui (oder anderen Frontend), den Rest nach bedarf, dazu gibts entsprechende Beschreibung auf der Download-Seite. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Samstag, 18. Oktober 2003 01:24 schrieb Manfred Tremmel:
Am Donnerstag, 16. Oktober 2003 23:07 schrieb Hans-Robert Wagner:
Wo soll die exakt sein? Ich habe eben noch einmal geschaut, nein es
ftp://packman.iu-bremen.de/testing/9.0
Da die Versionsnummer höher ist ale meine slebstübersetzte MPlayer-Version, habe ich mir eben den i686 Folder geladen.
Keine Ahnung von xine, ich wüste nicht einmal, was ich zu installieren hätte, die Auswahl ist groß.
libxine und xine-ui (oder anderen Frontend), den Rest nach bedarf, dazu gibts entsprechende Beschreibung auf der Download-Seite.
Danke für die Informationen, Robert
Am Samstag, 18. Oktober 2003 10:19 schrieb Hans-Robert Wagner:
libxine und xine-ui (oder anderen Frontend), den Rest nach bedarf, dazu gibts entsprechende Beschreibung auf der Download-Seite.
Danke für die Informationen,
Aber vorsicht, die xine-ui von der Packman-Seite scheint nicht mit SuSE 8.2 zu wollen, da sollte man also bei der Version bleiben, die SuSE mitliefert. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Donnerstag, 16. Oktober 2003 21:47 schrieb Manfred Tremmel:
Mit was spielst Du die ab? MPlayer und xine (sowie darauf aufbauende UIs wie kaffeine, kmplayer, kaboodle, ...) sind bei SuSE ja standardmässig ziemlich beschnitten. Von MPlayer gibts bei Packman ne SuSE 9.0er Version und die xine Variante für SuSE 8.2 tuts (wie mir inzwischen mehrfach bestätigt wurde) auch problemlos unter 9.0.
Hallo Manfred! Wieder mal vielen Dank. Nachdem ich libxine1 eingespielt habe, werden alle Filme, die ich habe, fehlerfrei von kaffeine abgespielt. Gruß, Dirk
-- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/
| http://packman.links2linux.de/
Manfred | http://www.knightsoft-net.de
participants (5)
-
David Haller -
Dirk Albrecht -
Hans-Robert Wagner -
Manfred Tremmel -
Rüdiger Meier