Das ultimative Podcasting-Tool des Tim P.

Beim 26. Chaos Communication Congress des Chaos Computer Clubs in Berlin gab es unter anderem eine Session von Tim Pritlove zum Thema „Podcasting-Tools“. Er hat ca. 30 Podcaster und Entwickler in einem Raum versammelt und mal aufgelistet, was das ultimative Podcasting-Tool alles können muss. Podcasting, das

Podcasting ist anders

Zunächst einmal machte Tim klar, dass Podcasting nicht dasselbe wie Radio ist. Sicherlich wachsen die Bereiche mehr und mehr zusammen, aber beim Podcasting hat man z.B. einen ganz anderen Workflow und vor allem auch kein festgelegtes Sendeschema. Weiterhin lebt ein Podcast teilweise auch mehr von einer Live-Community.

Auch ist die Verwendung von Blog-Software oder einem generischen CMS wie Drupal oder Plone nicht die beste Lösung, da ein Podcast eben kein Blog ist und andere Anforderungen hat.

Weiterhin ging es Tim auch nicht so sehr um die Postproduction von Audio oder Video, sondern hauptsächlich im die Infrastruktur drumherum, also das was vor oder während der Sendung passiert. Es geht also hier auch in erster Linie darum, eine Live-Sendung zu machen, die später auch als Podcast abzurufen ist.

Gesucht ist also ein vollkommen neues Tool.

Was soll das Tool können?

Im Prinzip soll das Tool in der Lage sein, alle anfallenden Daten zu einem Podcast und dessen Einzelfolgen zu speichern und sinnvoll aufzubereiten.

Dazu zählen z.B.

• allgemeine Podcast-Informationen wie
  • Podcast-Hosts
  • einfache Blogposts zu einem Podcast (Ankündigungen usw.)
  • dabei separater Blogfeed und Podcast-Feeds (wünschenswert vielleicht auch ein persönlicher RSS-Feed)
  • Kürzel des Podcasts (z.B. CRE für Chaos Radio Express)
• Pro Sendung/Folge:
  • Episodennummer/Kennziffer
  • Aufnahmedatum
  • Veröffentlichungsdatum
  • Timeline des Live-Chats mit besonderen Events wie
    • gute Anmerkungen
    • Links
    • Kapiteldefinitionen
  • Shownotes (ergänzend zu der Timeline, kann sich daraus ergeben)
  • verschiedene Formate des Podcasts, bspw.
    • MP4
    • MP3
    • mehrere Bandbreiten
  • evtl. Video-Aufzeichnung der Folge
• Community
  • Möglichkeit der Registrierung für Likes, Votes usw.

Da gibt es sicherlich noch weitere Daten, die speichernswert wären.

Der Workflow

Wichtig ist natürlich der Workflow. So ist es ja so, dass man irgendwann mal eine neue Folge machen will und in dieser eine unterschiedliche Anzahl von Personen teilnehmen kann (je nach Verfügbarkeit). Das will man dann entsprechend automatisiert ankündigen, es kann sich aber vielleicht doch wieder verschieben, es sind nicht alle pünktlich usw. Hat man den Podcast dann im Kasten geht es nur noch darum, den schnell online stellen zu können.

Schritt  1: Termin finden

Dies kann so ablaufen:

• Sendungsnummer ist bekannt, Titel/Thema vielleicht auch
• Man stimmt per Doodle-ähnlichem Tool einen Termin ab
  • alle potentiellen Teilnehmer bekommen eine E-Mail-Einladung
• Man sammelt Themen über eine Art Linkliste/Wiki (Scratchpad)
• Es wird automatisch ein Blogpost mit der Ankündigung erstellt (erscheint im Blogfeed, nicht Podcast-Feed)
• Es gibt einen Countdown auf der Seite
• Man kann sich evtl. per E-Mail informieren lassen
• Es könnte einen Kalender-Export geben
• Es gibt eine Anbindung an Twitter und andere Dienste zur Verbreitung des Termins
• Es muss eine Möglichkeit geben, den Termin auch noch zu verschieben wobei sich alle Ankündigungen automatisch aktualisieren
• Zur Zeit x (z.B. x=1 Stunde) vor dem Podcast gehen noch einmal Ankündigungen raus, dann sollte man wissen, dass es wirklich stattfindet

Schritt 2: Aufnahme

Das Kernstück ist die eigentliche Aufnahme, die live gestreamt wird und wo die Community aktiv mitmachen kann.

Hier wären schön:

• Ein Chat-System, z.B. ein eigener IRC-Server mit Bot
• Es sollte einen Login (OpenID, eigene Registrierung) geben
• Anonymes Mitmachen soll auch ermöglicht werden (evtl. eingeschränkt)
• möglichst einfache Kategorisierung von Metadaten, die zu einem Podcast reinkommen, wie URLs
• Bot könnte diese aufnehmen (z.B. über Bot-Kommandos, könnte auch erweiterbar sein)
• Sendestart muss dem Bot bekannt sein und muss auch später angepasst werden können
• Damit spätere synchrone Ausgabe der Timeline möglich (wirklich? was passiert, wenn man es schneidet?)
• System könnte evtl. auch die Aufnahme und Streaming mit anbieten, erstmal aber separat
• Moderatoren könnten Timeline-Events wie Chat oder URLs als Favoriten markieren so dass Nebenchats später nicht mehr angezeigt werden
• einfache Markierung von neuen Kapiteln, so dass diese später in den Podcast übernommen werden können

Schritt 3: Nach der Sendung

Bei Beendingung der Sendung wird zunächst das Chatprotokoll gespeichert.

Ein interaktiver Player sollte dann die (Video-)Aufnahme abspielen und das gespeicherte Protokoll kann synchron dazu ablaufen.

Weitere Möglichkeiten:

• Möglichkeit, später noch URLs und anderes zur Timeline hinzufügen zu können
• Um Nebenthemen auszublenden kann der Chat auch später noch gefiltert werden
• Einbau von Querverweisen zu anderen Episoden mit Zeitangabe, Bezug auf Kapitel?

Dann wurde noch ein wenig über Kapitel gesprochen:

• MP4 erlaubt Kapitel
• Tim speichert beim Aufnehmen im Moment z.B. noch Midi-Events und wandelt diese in Kapitel um oder markiert weniger gute Stellen usw.
• Kapitel gehören also in die Timeline als Metadaten
• Markierungen müssen sich in der Timeline später noch editieren lassen
• Bei MP4 kann man auch URLs in die Timeline packen. Dies macht nicht soviel Sinn bei iPods aber bei Webplayern schon
• Es fehlt teilweise dazu aber noch an Standards
• Es gibt auch eine Kapitel-Spezifikation für MP3
• Offen, wie die Zukunft von MP3 ausschaut

Es wurde auch noch diskutiert, ob man die Kapitel auch als Feeds anbieten kann so dass man aus jedem Kapitel sozusagen eine Folge macht. Damit bräuchte man keinen Kapitel-Support im Player. Es bleibt aber die Frage, ob da immer auch ne gute Pause zwischen den Kapitel ist.

Schritt 4: Publizierung und Feeds

Generell soll es möglichst viele Feeds in verschiedenen Formaten gaben. Man lädt also eine Datei hoch und diese soll automatisiert in x Versionen konvertiert werden, wobei diese eventuell auch in verschiedenen Bandbreiten angeboten werden. Diese könnte man zudem zeitversetzt publizieren um damit die Last auf dem Server etwas zu verteilen. Das Encoding könnte zudem auch auf Services wie EC2 ausgelagert werden. Man denke auch an Video.

Alle Metadaten usw. sollten vom System automatisch in die Dateien kopiert werden (Kapitel, URLs usw.). Auch wäre denkbar ein Intro und Outro automatisch anzuhängen.

Zudem wäre es wünschenswert auch externe Speicherorte angeben zu können, also z.B. S3. In diesem Zusammenhang wurde auch über Bittorrent gesprochen, was Tim als die Zukunft für Podcasting ansieht, vor allem, wenn es sich um High Definition-Videopodcasts handelt. Auch solch etwas kann ein System anbieten, man muss allerdings aufpassen, keinen offenen Tracker zu betreiben.

Auch HTTP-Streaming wurde noch genannt.

Statistik

Besonders wichtig war Tim die Statistik (und leider habe ich das nicht so genau mitgeschrieben, also vielleicht nochmal in die Aufzeichnung reinhören). Hier ist das Problem, dass einfache Web-Statistik-Tools oder auch ein grep in die Irre geführt werden, da oftmals Dateien nur in Teilen heruntergeladen werden. Tim behilft sich damit, dass er alle Zeilen des Logfiles durchgeht und die Bytezahl der Responses einer Sendung aufaddiert um sie danach durch die Filesize zu teilen. So hat er dann die wirklich Anzahl von heruntergeladenen Episoden. Dies sollte ein Tool natürlich automatisiert machen.

Bei Benutzung von Bittorrent wurde dies ebenfalls angesprochen, aber da kann man die Anzahl der Seeder als fertige Downloads zählen, denn Seeder sein bedeutet nichts anderes und Bittorrent-Server können das damit auch automatisch erkennen.

Zum Ende hin wurde noch über verschiedene Details gesprochen und u.a. auch über begonnene Entwicklungen aufbauend auf Drupal. So ein komplettes Tool gibt es allerdings (wie zu erwarten) noch nicht.