Von Ikone des guten Geschmacks am So, 27. Mai 2007 um 14:01 #
Phonon (und KDE allgemein) kann doch ein ganzes stück mehr als gstreamer (und Gnome). Echt? Phonon ganz allein kann mehr als Gstreamer alleine? Verrat das mal den KDE-Entwicklern, die denken nämlich es ist nur eine Abstraktionsschicht zu Multimediaframeworks wie z.B. gstreamer. :) Schenke ich dir: http://www.clueponbook.com/cluepon.html
Von Ikone des guten Geschmacks am So, 27. Mai 2007 um 15:05 #
heute (2007) Danke. Ich habe mich gerade gefragt welches Jahr wir haben. :p
ist es kaum einsetzbar, da einfach zu vieles nicht funktioniert. Also wenn die Gstreamer-Nutzung von zahlreichen Musikplayern (Rhythmbox, banshee, exaile....), Musikeditoren(Jokosher), Videoeditoren(pitivi), Rippern(soundjuicer,thoggen) und auf Embedded Devices (N770/800) bei dir "kaum einsetzbar" bedeutet... Soll man das jetzt als sprachliche Ungenauigkeit oder mangelndes Sachverständniss deinerseits einordnen? Naja, kannst ja selbst auswählen, oder? :)
* Rhythmbox, Totem usw. offerieren auch Xine als Backend. * GSTreamer ist dafür bekannt, von heute auf morgen ebend mal die API zu brechen. * Hat GStreamer von 1999 an bis einschliesslich 2007 mit oben genannten Probleme. * Daher bietet KDE die Phonon Abstraktionsschicht an, um genau dieser Problematik entgegen zu wirken. * Ich kann über die Embedded Devices N770 und N800 nicht mitreden, vermutlich hat man hier aber eine "letztmals" stabile Version von GStreamer benutzt und darauf aufgebaut.
Zum Thema "mangelndes Sachverständnis" möchte ich dich auf folgende - ebenfalls mit mangelndem Sachverständnis beglückten namenhaften Personen aus dem Open Source Umfeld verweisen.
Von Ikone des guten Geschmacks am So, 27. Mai 2007 um 15:55 #
Nochmal Fakten Ja wo sind sie denn für deine Aussage, dass gstreamer kaum benutzbar ist?
* Rhythmbox, Totem usw. offerieren auch Xine als Backend. Ich hatte dich doch gebeten, dich vorher zu informieren. Ist das denn so schwer? Rhythmbox bietet schon seit längerem keinen Support mehr für xine. Ich bezweifle sogar, dass es sich noch mit xine bauen lässt. Desweiteren ist es kein Argument für Unbrauchbarkeit des einen Frameworks, wenn Applikationen auch ein anderes Backend unterstützen. Umgedreht wird ein Schuh draus: Es spricht gegen ein Framework, würde es nicht benutzt werden. Dein "Fakt" ist also keins.
* GSTreamer ist dafür bekannt, von heute auf morgen ebend mal die API zu brechen. * Hat GStreamer von 1999 an bis einschliesslich 2007 mit oben genannten Probleme. Von heute auf morgen wurde gar nix gebrochen. Und das Problem mit den APIs haben alle Projekte. Oder wo ist da der Unterschied zwischen dem guten API-Bruch bei QT (gibt ja immerhin schon 4 Versionen) und dem schlechten API-Bruch bei Gstreamer? Sowohl QT als auch Gstreamer bieten i.Ü. die Möglichkeit beides parallell zu installieren.
* Ich kann über die Embedded Devices N770 und N800 nicht mitreden, vermutlich hat man hier aber eine "letztmals" stabile Version von GStreamer benutzt und darauf aufgebaut. Was ist das denn für ein Schwachsinn? Was sollen sie denn sonst verwenden? Die Version aus dem Trunk? o_O
* Daher bietet KDE die Phonon Abstraktionsschicht an, um genau dieser Problematik entgegen zu wirken. Wieder nur heiße Luft. KDE will sich nicht von einem Framework abhängig machen. Dass man Gstreamer unterstützt spricht gegen deine These der Unbenutzbarkeit. Oder machen sich die KDE-Entwickler die Mühen für etwas, dass laut deiner "Fachaussage" unbenutzbar ist. ;)
Ach und zu deinen Links: Ich habe sie schon gelesen und verstanden. Du ganz offensichtlich nicht.
Zu Rhythmbox und Totem und alles was GStreamer unter GNOME benutzt. Als jemand der Regelmäßig GNOME in den vergangenen Jahren gebaut hat, kann ich dir bestätigen, es schon immer die Hölle war GSTreamer gescheit mit GNOME zum Bauen zu bewegen. Lange Zeit galt gnome-media als nicht baubar, da es immer noch auf GST 0.8 basierte und nicht GST 0.10. Gleiches war mit Rhythmbox und Totem, mal lies sich das Eine mit 0.9 compilieren, mal das Andere und das in einem gesamten was GNOME entsprechen sollte.
Zu Qt, es heisst Qt von Trolltech und nicht QT alias Quick Time von Apple
Zu Phonon. Phonon bietet eine Abstraktionsschicht zu unterschiedlichen Multimedia engines. Dazu gehört leider nunmal auch GStreamer. Gut jedoch, dass man unter KDE nicht dazu gezwungen wird, da man auch Xine verwenden kann. Die KDE Entwickler schaffen nur eine Schnittstelle zu GStreamer, mehr nicht.
Zu den Links, Sie geben genau das wieder, was die KDE Entwickler als Probleme deuten und zwar genau das, welches du mich "ums mal so auszudrücken" einen Lügner titulierst. Nämlich, dass man daher kein GSTreamer direkt verwenden möchte, gerade weil hier die API nie konsistent gehalten wird. Warum liest du dir nicht die Links durch ?
Zitat: http://www.pro-linux.de/news/2006/9688.html "Kritiker dieser Position merken an, dass GStreamer kein stabiles API für die Lebensdauer von KDE 4 bereitstellen könne."
Zitat: http://aseigo.blogspot.com/2006/05/id-like-another-black-eye-please.html "a believable API/ABI stability guarantee that covers kde4's lifespan"
Nämlich, dass man daher kein GSTreamer direkt verwenden möchte, gerade weil hier die API nie konsistent gehalten wird. Nenne mir eine verbreitete Bibliothek, deren API nie verändert wurde. Du kannst wohl kaum verlangen, dass GStreamer auch noch in 10 Jahren das gleiche API verwendet. Das wird auch bei den kdelibs nicht so sein, da bis dahin KDE 5 oder eher KDE 6 draußen ist.
"Kritiker dieser Position merken an, dass GStreamer kein stabiles API für die Lebensdauer von KDE 4 bereitstellen könne." Und KDE bietet kein stabiles API für die Lebensdauer von Linux. Das Problem ist hier doch, dass KDE bezüglich der Major-Releases an Qt angepasst ist. API-Wechsel von Qt bedeuten daher, dass KDE irgendwann umgeschrieben werden muss. Man will sich halt nicht noch eine Abhängigkeit bezüglich APIs hinzuholen.
Aber das hat wiederum nichts mit GStreamer an sich zu tun. Man traut sich ja zum Glück auch nicht, irgendeine andere Bibliothek fest zu verdrahten.
Echt? Phonon ganz allein kann mehr als Gstreamer alleine? Verrat das mal den KDE-Entwicklern, die denken nämlich es ist nur eine Abstraktionsschicht zu Multimediaframeworks wie z.B. gstreamer. :)
Schenke ich dir: http://www.clueponbook.com/cluepon.html
Danke. Ich habe mich gerade gefragt welches Jahr wir haben. :p
ist es kaum einsetzbar, da einfach zu vieles nicht funktioniert.
Also wenn die Gstreamer-Nutzung von zahlreichen Musikplayern (Rhythmbox, banshee, exaile....), Musikeditoren(Jokosher), Videoeditoren(pitivi), Rippern(soundjuicer,thoggen) und auf Embedded Devices (N770/800) bei dir "kaum einsetzbar" bedeutet...
Soll man das jetzt als sprachliche Ungenauigkeit oder mangelndes Sachverständniss deinerseits einordnen? Naja, kannst ja selbst auswählen, oder? :)
* Rhythmbox, Totem usw. offerieren auch Xine als Backend.
* GSTreamer ist dafür bekannt, von heute auf morgen ebend mal die API zu brechen.
* Hat GStreamer von 1999 an bis einschliesslich 2007 mit oben genannten Probleme.
* Daher bietet KDE die Phonon Abstraktionsschicht an, um genau dieser Problematik entgegen zu wirken.
* Ich kann über die Embedded Devices N770 und N800 nicht mitreden, vermutlich hat man hier aber eine "letztmals" stabile Version von GStreamer benutzt und darauf aufgebaut.
Zum Thema "mangelndes Sachverständnis" möchte ich dich auf folgende - ebenfalls mit mangelndem Sachverständnis beglückten namenhaften Personen aus dem Open Source Umfeld verweisen.
Quellenverweise:
http://www.pro-linux.de/news/2006/9688.html
http://aseigo.blogspot.com/2006/05/id-like-another-black-eye-please.html
http://amarok.kde.org/blog/archives/91-Backends,-Phonon,-GStreamer.html
Ja wo sind sie denn für deine Aussage, dass gstreamer kaum benutzbar ist?
* Rhythmbox, Totem usw. offerieren auch Xine als Backend.
Ich hatte dich doch gebeten, dich vorher zu informieren. Ist das denn so schwer? Rhythmbox bietet schon seit längerem keinen Support mehr für xine. Ich bezweifle sogar, dass es sich noch mit xine bauen lässt.
Desweiteren ist es kein Argument für Unbrauchbarkeit des einen Frameworks, wenn Applikationen auch ein anderes Backend unterstützen. Umgedreht wird ein Schuh draus: Es spricht gegen ein Framework, würde es nicht benutzt werden. Dein "Fakt" ist also keins.
* GSTreamer ist dafür bekannt, von heute auf morgen ebend mal die API zu brechen.
* Hat GStreamer von 1999 an bis einschliesslich 2007 mit oben genannten Probleme.
Von heute auf morgen wurde gar nix gebrochen. Und das Problem mit den APIs haben alle Projekte. Oder wo ist da der Unterschied zwischen dem guten API-Bruch bei QT (gibt ja immerhin schon 4 Versionen) und dem schlechten API-Bruch bei Gstreamer? Sowohl QT als auch Gstreamer bieten i.Ü. die Möglichkeit beides parallell zu installieren.
* Ich kann über die Embedded Devices N770 und N800 nicht mitreden, vermutlich hat man hier aber eine "letztmals" stabile Version von GStreamer benutzt und darauf aufgebaut.
Was ist das denn für ein Schwachsinn? Was sollen sie denn sonst verwenden? Die Version aus dem Trunk? o_O
* Daher bietet KDE die Phonon Abstraktionsschicht an, um genau dieser Problematik entgegen zu wirken.
Wieder nur heiße Luft. KDE will sich nicht von einem Framework abhängig machen. Dass man Gstreamer unterstützt spricht gegen deine These der Unbenutzbarkeit. Oder machen sich die KDE-Entwickler die Mühen für etwas, dass laut deiner "Fachaussage" unbenutzbar ist. ;)
Ach und zu deinen Links: Ich habe sie schon gelesen und verstanden. Du ganz offensichtlich nicht.
Zu Rhythmbox und Totem und alles was GStreamer unter GNOME benutzt. Als jemand der Regelmäßig GNOME in den vergangenen Jahren gebaut hat, kann ich dir bestätigen, es schon immer die Hölle war GSTreamer gescheit mit GNOME zum Bauen zu bewegen. Lange Zeit galt gnome-media als nicht baubar, da es immer noch auf GST 0.8 basierte und nicht GST 0.10. Gleiches war mit Rhythmbox und Totem, mal lies sich das Eine mit 0.9 compilieren, mal das Andere und das in einem gesamten was GNOME entsprechen sollte.
Zu Qt, es heisst Qt von Trolltech und nicht QT alias Quick Time von Apple
Zu Phonon. Phonon bietet eine Abstraktionsschicht zu unterschiedlichen Multimedia engines. Dazu gehört leider nunmal auch GStreamer. Gut jedoch, dass man unter KDE nicht dazu gezwungen wird, da man auch Xine verwenden kann. Die KDE Entwickler schaffen nur eine Schnittstelle zu GStreamer, mehr nicht.
Zu den Links, Sie geben genau das wieder, was die KDE Entwickler als Probleme deuten und zwar genau das, welches du mich "ums mal so auszudrücken" einen Lügner titulierst. Nämlich, dass man daher kein GSTreamer direkt verwenden möchte, gerade weil hier die API nie konsistent gehalten wird. Warum liest du dir nicht die Links durch ?
Zitat: http://www.pro-linux.de/news/2006/9688.html
"Kritiker dieser Position merken an, dass GStreamer kein stabiles API für die Lebensdauer von KDE 4 bereitstellen könne."
Zitat: http://aseigo.blogspot.com/2006/05/id-like-another-black-eye-please.html
"a believable API/ABI stability guarantee that covers kde4's lifespan"
Planlos und lernresistent trifft es wohl eher. Hast du gerade eben wieder bewiesen.
Nenne mir eine verbreitete Bibliothek, deren API nie verändert wurde. Du kannst wohl kaum verlangen, dass GStreamer auch noch in 10 Jahren das gleiche API verwendet. Das wird auch bei den kdelibs nicht so sein, da bis dahin KDE 5 oder eher KDE 6 draußen ist.
"Kritiker dieser Position merken an, dass GStreamer kein stabiles API für die Lebensdauer von KDE 4 bereitstellen könne."
Und KDE bietet kein stabiles API für die Lebensdauer von Linux. Das Problem ist hier doch, dass KDE bezüglich der Major-Releases an Qt angepasst ist. API-Wechsel von Qt bedeuten daher, dass KDE irgendwann umgeschrieben werden muss. Man will sich halt nicht noch eine Abhängigkeit bezüglich APIs hinzuholen.
Aber das hat wiederum nichts mit GStreamer an sich zu tun. Man traut sich ja zum Glück auch nicht, irgendeine andere Bibliothek fest zu verdrahten.
Ja, da es eine vollkommen andere Aufgabe hat, ist es auf seinem Gebiet überlegen.
http://www.clueponbook.com/cluepon.html
http://www.clueponbook.com/cluepon.html