Posts mit dem Label MediaMasher werden angezeigt. Alle Posts anzeigen
Posts mit dem Label MediaMasher werden angezeigt. Alle Posts anzeigen

C++: Plugins the QT way

Posted by : MOnsDaR | Freitag, 7. Mai 2010 | Published in

Compared to modern languages like C# or Java, C++ lacks in support of dynamically loading code at runtime. It is not easy to implement a portable plugin-framework, but it is possible. Luckily there are frameworks available which make such a functionality possible.

Nokias QT-Framework is one of the most active and best maintained frameworks for C++. Besides the famous GUI-functionality are some neat features like reimplementations of the std-features Lists, Strings, Maps etc. It also has a plugin-framework integrated. For testing purposes, I wrote the MediaMasher plugin-architecture in C++ with QT-Plugins:

SourceFactory

(click on image for resize)

The finished project is uploaded to a git-repository and could be downloaded HERE.

It includes a library which adopts the above UML-architecture. Additionally a binary using the lib with a hardcoded sample-source is included. The path points to a systemsound in Ubuntu 10.04. It could be easily changed in /test/TestMain/main.cpp

For building the project CMake is needed. It was another goal for me to demonstrate how QT and QPlugin could be included in such a build-environment.

Unfortunately there is not much documentation about QPluginLoader and the related mechanisms. Besides an official Plug and Paint example directly in the QT-documententation is just the class reference. There isn’t much info in blogs or by projects using this framework.

Finally I’ll show the POCO-Framework as an alternative to the QT-framework. The ClassLoader-component could be interesting for commercial projects which could not effort a QT developer licence (commercial licences start at 3000€ for QT)

Just ask if there are any questions about the example-code or if I should give some deeper explanation.

MediaMasher: Pluginframework läuft

Posted by : MOnsDaR | Samstag, 20. Februar 2010 | Published in

Die freie Zeit am heutigen Samstag habe ich genutzt, um ein wenig am MediaMasher zu basteln.

Assembla
Das Projekt hat schon seit einigen Tagen einen Space bei Assembla. Dieser wird derzeit primär als Subversion-Hoster genutzt. Später kann aber auch die Wiki-Funktion oder ein Bugtracker-System genutzt werden.
Falls sich jemand für den derzeitigen Stand interessiert, kann er HIER auf das Subversion-Repository zugreifen.

Plugin Framework
In letzter Zeit habe ich meine ersten richtigen Schritte in Python gemacht und versucht, ein Pluginframework für Sourceplugins zu implementieren. Ein Klassendiagramm vom Aufbau habe ich ja bereits im ersten MediaMasher-Artikel gepostet.
Seit heute (Revision 12) läuft das Ganze nun. Bisher gibt es Plugins, um HTTP-Quellen und lokale Dateien in abspielbare URIs umzuwandeln.

GUI
Als Hauptprogramm habe ich eine sehr einfache GUI (ohne Inhalt) erstellt, die eigentlich nur als Hülle für Phonon dient.

Derzeitiger Stand
Es ist momentan möglich, eine gegebene URI in eine abspielbare Source zu konvertieren und diese dann abzuspielen.
Mal sehen, was ich demnächst in Angriff nehme. Bevor ich die GUI erstelle, sollte zunächst der Rest stehen. Das heißt ein einfaches Package für die Datenbank-Anbindung wird erstellt. Auch wäre ein etwas "intelligenteres" Plugin für einen Dienst wie Youtube oder Dailymotion denkbar.

MediaMasher: Umsetzung via kioslaves?

Posted by : MOnsDaR | Dienstag, 16. Februar 2010 | Published in

Ein Entwickler in #python.de machte heut den Vorschlag, so etwas wie MediaMasher doch mit den KDE I/O Slaves (kioslaves) zu lösen.

Doch was sind kioslaves? (es folgt eine einfache, technisch nicht 100%ig richtige Erklärung)
Unter KDE greift man mit dem Konqueror (Counterpart zum Windows Explorer) nicht direkt auf die Dateien des Dateisystem zu, sondern nur auf eine Zwischenschicht. Diese Schicht liefert dem User die jeweiligen Dateien, die hinter dem Dateipfad liegen. Im Normalfall sind das wie unter Windows bekannt ganz normale Dateien:

Allerdings ist mehr möglich, als sich nur die Dateien hinter einem Dateipfad anzeigen zu lassen.
So kann man durch Eingabe von
ftp://ServerAdresse/Ordner/
direkt auf einen FTP-Server zugreifen. Die Dateien und Ordner auf dem Server werden angezeigt wie normale Dateien auf der Festplatte auch.

Ein anderes Beispiel ist die Eingabe von
audiocd:/
Hierdurch wird der Inhalt der zurzeit eingelegten Audio-CD angezeigt. Zusätzlich befindet sich ein Ordner "ogg" in der Anzeige. In diesem sind die Songs der CD in das freie Soundformat Ogg-Vorbis konvertiert. Wie aus einem normalen Ordner kann man die Dateien in andere Ordner der Festplatte kopieren.

Dies war nur eine kleine (technisch nicht 100% richtige) Einführung in kioslaves, wer mehr erfahren möchte, kann sich in einem Artikel auf Pro-Linux.de informieren.


Was hat das Ganze jetzt mit dem MediaMasher zu tun? 
Denkbar wäre es, eine neue URI youtube:// einzuführen. So würde der Link
http://www.youtube.com/watch?v=ABnyHNgE2Q8
So dargestellt werden:
youtube://ABnyHNgE2Q8
Dem User würden als "Ordnerinhalt" die verschiedenen Videos dargestellt werden, die man sich unter der Url anschauen kann. Neben dem Standardformat gibt es ja auf Youtube seit einiger Zeit auch Videos in HD-Auflösung.

Mit einem Player, der dies unterstützt, könnte man "Dateien" in diesem Ordner zur Medialibrary hinzufügen. Dass die Videos dabei garnicht von der Festplatte kommen, würden weder Player noch User merken.

Nachteile:
Leider ist die KDE Software Compilation derzeit noch nicht vollständig portabel und derzeit nur unter Linux wirklich einsetzbar. Auch würde der Einsatz von kioslaves weitaus mehr abhängige Programme mit sich ziehen, wenn man das Ganze auf einem anderen System wie Windows installieren möchte.
Hinzu kommt, dass das Konzept der kioslaves noch in den Kinderschuhen steckt.
Fazit:
Eine wirkliche Alternative zum MediaMasher sind die kioslaves nicht, jedoch ein interessanter Ansatz, dasselbe Problem zu lösen. Wer weiß, wie sich das Projekt entwickelt und ob nicht in einigen Jahren solch ein System zum Standard avanciert ist.

Ich habe in den Bugtracker des KDE-Projekts mal einen Wish eingetragen, der in etwa dasselbe enthält wie in diesem Blogeintrag.

Projektidee: MediaMasher

Posted by : MOnsDaR | Samstag, 13. Februar 2010 | Published in

Worum gehts?
Wenn man sich abseits von überteuerten Alben und Singles im nächsten Plattenladen neue Musik anhören möchte, gibt es online wie auch offline haufenweise legale Möglichkeiten.

Neben dem altbewährten Radio oder Diensten wie Grooveshark und Last.fm kann man inzwischen auch auf Youtube, DailyMotion oder MyVideo Songs seiner Lieblingsinterpreten in guter Qualität anhören.
Letztgenannte Videopages haben inzwischen Verträge mit größeren Musiclabeln und bieten meist auch das passende Musikvideo mit an.

Neben der altgedienten MP3, die man via ITunes oder Napster (meist inklusive nervigem DRM) erwerben kann, gibt es also noch eine ganze Menge weiterer möglicher Quellen für Musik.

Die Idee
Wenn man etwas darüber nachdenkt, liegt auf der Hand, was jetzt kommt:
Ein Musikplayer, dem es egal ist, wo die Musik herkommt. Ein Song verfügt nicht mehr nur über einen Dateipfad zur lokalen MP3 sondern alternativ über einen Link zum entsprechenden Youtube-Video oder einem FTP-Server der Musikdateien enthält.
Natürlich kann Musik nicht nur via MP3 kodiert sein, andere Formate wie ogg oder wma sind möglich. Wenn ein passendes Video enthalten ist, gibt es viele weitere Möglichkeiten wie mp4, wmv, avi oder mkv.

Das Design
Datenbank
Songs sollten wie oben schon beschrieben, mehr als eine mögliche Quelle enthalten. Ein Song wird nicht mehr durch eine Datei auf der Festplatte beschrieben.
Um als Player zu funktionieren, sollte der MediaMasher mehr als einen Song am Stück abspielen können, weshalb die Datenbank um eine Playlist-Tabelle erweitert wird.
Abseits der funktionalen Anforderungen an die Datenbank kann man natürlich noch einige Tabellen und Attribute für Zusatzinformationen hinzufügen. Von Interpreten über Genres, Bewertungen, Alben bis hin zum Entstehungsjahr des Songs ist alles denkbar.




Ein großer Vorteil der dezentralisierten Datenhaltung ist, dass Songs auf jedem Computer mit Netzzugang abgespielt werden können. Das heißt im Klartext:
Man kann die Libraries von Freunden und Bekannten übernehmen, diese mergen und somit eine große Datenbasis aufbauen, die bei allen Usern gleichgut funktioniert.

Weiterhin muss für einen Song nurnoch angegeben werden, wo er sich befindet. Es hängt keine große Datei mehr an ihm.
Eine Musiksammlung mit mehreren tausend Songs wäre lediglich einige Kilobyte groß und könnte überall abgespielt werden.

Programmlogik
Nicht jede Source kann direkt abgespielt werden. Der Youtube-Link gibt nicht preis, wo sich die dazugehörige flv-Datei befindet.
MediaMasher muss in der Lage sein, eine gegebene URI in ein abspielbares Format zu bringen.
Hier kann man wie unten dargestellt eine Factory programmieren, die durch Plugins erweitert werden kann und gegebene URIs in abspielfähige Sources verwandelt.


Wie im Bild dargestellt gibt es mehrere Plugins, die jedes für einen bestimmten URI-typ zuständig sind. Je nachdem, welche Plugins ein User hat, kann er andere URIs abspielen.
Mit der Funktion isResponsible() kann die Factory überprüfen, ob ein Plugin eine gegebene URI verarbeiten kann.
Die Funktion getSource() gibt dann die entsprechende Mediasource zurück.

Abspielen der Sources
Derzeit ist unter der Haube des KDE-Projekts unterstützt von den QT-Entwicklern die Multimedia-Library Phonon in Entwicklung.
Phonon kann nahezu alle übergebenen Sources abspielen. Hierbei werden alle auf dem System installierten Codecs genutzt.
Phonon und seinen Möglichkeiten werde ich demnächst sicherlich noch den ein oder anderen Blogeintrag widmen.

GUI
Die Oberfläche des Players sollte relativ einfach gehalten sein. Wer den WinAmp-Lite kennt, weiß wie simpel ein guter Mediaplayer aussehen kann.
Zusätzlich zur Player-Oberfläche muss es noch Möglichkeiten geben, neue Songs hinzuzufügen, die Library zu bearbeiten oder zu ex/importieren.
Natürlich kann man bei fortschreitendem Entwicklungsstand auch die GUI entsprechend erweitern.

Die Umsetzung
Derzeit bin ich nach Feierabend ab und an dabei, das Design des MediaMashers zu erarbeiten.
Das Programm sollte sehr leicht zu verwenden und zu erweitern sein. Portabilität und modularer Aufbau sind sehr wichtig.

Die Sprache Python erfüllt alle oben genannten Kriterien. So bietet mir das Projekt also eine gute Möglichkeit, endlich mal Python zu lernen.

Für die GUI und die Soundwiedergabe kann der Python-Port PyQt4 genutzt werden. Die Datenbasis lässt sich mit dem eingebauten SQlite-Support ansprechen und Plugins lassen sich auch einfach realisieren.


Ich werde euch natürlich auf dem laufenden halten, was den Fortschritt des Projektes und mein Abenteuer mit Python angeht.
Stay tuned ;)