Echtzeitübertragung von Bild und Ton im Internet
Audio- und Videostreaming im Internet gibt es zwar schon lange, gehört aber zu den Technologien, die sich vergleichsweise langsam etabliert haben, da lange über Formate und Protokolle gestritten wurde. In letzter Zeit zeichnen sich aber neue Tendenzen ab, die die Echtzeitübertragung von Bild und Ton im Netz sowohl potentiellen Sendern als auch Empfängern einfacher zugänglich machen könnten.
Im Gespräch mit Tim Pritlove erläutert Nikolai Longolius Geschichte und Technik von Streaming-Protokollen und -Formaten. Dabei kommen unter anderem zur Sprache: Streaming vs. Progressive Download, Server-basierter Direktzugriff auf Mediendateien, Container und Codecs, Struktur einer streambaren Datei, die Bedeutung von Key Frames, Mitschneiden von verschlüsselten Streams, proprietäre und freie Streaming Server, der Trend zu HTTP-basiertem Streaming, Restriktive Lizenzen vs. freie Codecs, Livestreaming-Dienste und anderes.
Shownotes
Links:
- Nikolai Longolius / Lionradio
- WP: Spiegel TV
- WP: XXP
- schnee von morgen webTV
- WP: Progressive download
- WP: Streaming Media
- WP: Lighttpd
- H264 Streaming Module for Lighttpd
- CRE061 Medienformate und Codecs
- WP: Key frame
- WP: Cars
- WP: RealAudio
- WP: Real-Time Transport Protocol (RTP)
- WP: Real-Time Streaming Protocol (RTSP)
- WP: Real Time Messaging Protocol (RTMP)
- WP: User Datagram Protocol (UDP)
- WP: Transmission Control Protocol (TCP)
- WP: Microsoft Media Server Protocol (MMS)
- WP: Adobe Flash
- WP: Windows Media Player
- WP: H.264
- WP: Adobe Flash Media Server
- WP: Red 5
- WP: Flash Video (FLV)
- WP: H.263
- WP: Sorenson Codec
- WP: VP6
- Wowza Media Server
- x264
- WP: Theora
- WP: Icecast
- WP: Darwin/QuickTime Streaming Server
- WP: Replay-Angriff
- Xenim Streaming Network
- Microsoft Media Server
- HTTP Live Streaming
- WP: PLS Datei
- WP: Property List
- Bundesradio Wahlstudio
- WP: Content Distribution Networks
- WP: Akamai
- WP: Webcache
- WP: HTML5
- MPEG LA
- MPEG LA AVC/H.264 FAQ
- WP: Geotargeting
- WP: Unicast
- WP: Multicast
- Livestream
- UStream
- WP: QuickTime Broadcaster
- Flash Media Encoder
- P2PCast: A Peer-to-Peer Multicast Scheme for Streaming Data [PDF]
Erster!
Ich ziehe grad mit 30kB/s, und bin gespannt. :)
Oh, *darauf* hab ich schon gewartet! Laptop, UMTS, Kamera und dann live streamen. Ich bin 2 Fernsehsender.
Es ist zwar halb OT, aber es gibt im Moment eine Aktion namens „Desert Bus for Hope“ bei der die Leute von http://www.loadingreadyrun.com/ versuchen Geld für Child’s Play zu sammeln.
Deshalb spielen die das langweiligste Computerspiel der Welt: Desert Bus. Dieses Spiel besteht darin einen Bus auf einer geraden Strecke zu fahren. Je mehr Spenden die bekommen um so länger fahren sie.
Das Ganze wird auf 2 UStream Streams gestreamt:
http://desertbus.org/
Hallo,
sehr tolle Sendung. Also freie und sehr gute Streaming-Server sei noch ist noch http://www.flumotion.net/ zu erwähnen. Glaube das Linux-Magazin nutzt den, für ihr Streaming-Portal. In einem UNI Projekt hat er sehr gute Dienste vollbracht.
Ohh that mit dem Header am Schluss ist komplizierter. Man weiß ja nicht, wie groß dieser Header sein wird, da die Liste der Keyframes ja unterschiedlich groß sein kann. Dadurch müsste man nach der Aufzeichnung die komplette Datei neu kopieren. Das ist wirklich deutlich aufwändiger als ein einfacher seek and Anfang der Datei.
CRE ohne Intro? Ich bin ein bischen enttäuscht.
Ansonsten natürlich wie immer tolle Sendung! Super mal wieder Technik.
rtmpdump kann rtmpe. Und bei rtmpe scheint es sowieso nicht viel zu knacken zu geben, ausser Adobe hätte rtmpe mal erneuert, dass wüsst ich nich.
Aber kann ma ja hier ma nachlesen: http://lkcl.net/rtmp/
Icecast macht das Ogg/Theora wie auch Ogg/Vorbis und Mp3 über HTTP. Bei den bisherigen Experimenten mit Theora würde ich auch nicht sagen, dass das sonderlich problemlos läuft (zB schlechte Unterstützung durch Player & Source-Clients).
Ansonsten ein brauchbarer Überblick, aber zumindest für mich nicht viel Neuess
Header am Ende:
Das hat einen guten Grund. Z.B. wenn man in seiner 81,5 MB CRE MP3 tags ändern will, muss nicht die ganze Datei neu geschrieben werden, sondern nur das Dateiende. Bei wirklich großen Datein macht das schon einen Unterschied.
HTTP Range Request:
Das hat ja schon selbst Winamp 2 schon gekonnt! So funktionierte das seeking in den shoutcast und nullsoft tv Streams!
Apropos:
Nullsoft tv hat ihre Videos auch pseudo verschlüsselt. Irgend so ein ultravox encoding/scrambling Ding. Gibts mittlerweile eh Decoder. Ich hab einen anderen weg gefunde sich die gedumpten Videos anzuschaun als es das noch nicht gab: Mit einen lokalen Webserver sich die Videos selber streamen. Ja, das DRM war so schlecht das ein einfaches Replay funktioniert hat. Nichtmal die Serveradresse wurde überprüft. Hab fast das Gefühl das habens Alibi haft absichtlich so gemacht. Nullsoft (die Software Firma hinter Winamp) haben selber ja auch einiges an Open Source libs rausgebracht und bringen ja auch Support für Ogg Vorbis und ich glaub auch Flac built in mit.
Bei MP3 sind die ID3-Tags deshalb am Ende, damit das halbwegs kompatibel bleibt. ID3 kam nämlich erst später und normale MP3-Player müssen damit zurecht kommen. Wäre das am Anfang, so könnte der MP3-Player sagen, dass die Datei kaput ist.
Zu dem HTTP-Streaming per Client: Das ist eigentlich genau das, was der Player sowieso machen muss. Ein Player für Dateien kann sich ja auch nicht die ganze Datei in den RAM laden, sondern muss dabei Seeken und einzelne Blöcke lesen.
Was ich mich eigenlich frage, wo bleibt eigentlich Peer-to-Peer Streaming? Das sollte doch eigentlich relativ einfach zu machen sein. Man unterteilt den Live-Stream in kleine Häppchen in der Größe von GOPs, und verteilt die ähnlich wie bei Bittorrent. Mit ein paar GOPs Verzögerung würde das dann bei jedem ankommen. GOPs kann man auch gut rekodieren um beispielsweise die Bandbreite einstellen zu können, oder auf einen anderen Codec zu wechseln.
Microsofts Silverlight benutzt HTTP Streaming. Im Verlgeich zu Flash sollen die auch bei HD besser sein. Ich habe eine Artikel darüber gelesen und was ich daran besonders interessant fande, dass die Techniken benutzen um die Videoqualität an Netzwerkverbindung und Client anzupassen. Die messen die Round Trip Time, Downloadrate etc und adaptieren die Qualität dann.
Ich hab noch was gelesen ;). Google gibt (zu mindest relativ) kaum was aus für seinen Traffic. Das schaffen die durch viele Peeringverträge (http://en.wikipedia.org/wiki/Peering) mit anderen Netzen. Aber das kann natürlich nur jemand, der die Größe von Google hat. Als kleiner Einzelkämpfer ist der Traffic doch das größte Problem
RTMPE ist bereits geknackt. Das tool rtmpdump kann verschlüsselte Flash-Streams dumpen.
Es ist teilweise etwas aufwändig die nötigen Metadaten aus dem Netzwerk-Traffic zu extrahieren. Der URL alleine reicht oft nicht aus.
Aber es funktioniert. Hab ich schon erfolgreich getestet. :)
Zu erwähnen ist vielleicht noch, dass Adobe damals dafür gesorgt hat, dass das rtmpdump-Projekt bei sourceforge raus geflogen ist.
streisand-effect galore :)
P2P- Streaming gibts bereits seit längerem (siehe StreamTorrent, Sopcast, etc.). Leider sind noch nicht viele auf diesen Zug gesprungen. Interessant wird aber zu sehen, inwiefern das neue Flash 10.1 bei YouTube und ähnlichen Seiten Verbreitung finden wird, denn mit der neuen (Beta?) Version ist soweit ich weiss auch die Grundlage für P2P Streaming geschaffen worden.
Bezüglich P2P kommt aus Japan auch schon seit längerem diese praktische Software:
http://keyholetv.jp/english/index.html
Ja, schön dass es wieder regelmäßig hier Folgen gibt! Aber ich vermisse schmerzlich die Soundschnipsel, die früher immer das Intro eingeleitet haben! Ich hoffe doch da wird was nachgereicht.
Für WindowsMedia-Streaming ist der Server Bestandteil von Win2003 / Win2008 Server.
http-Streaming heißt bei Microsoft „Smooth Streaming“. Dazu braucht man einen IIS + (kostenlosen) Media Service. Eine gute Formatbeschreibung hier: http://alexzambelli.com/blog/2009/02/10/smooth-streaming-architecture/
Klasse Folge.
Ich finde es gut das ihr zur Winterzeit etwas mehr Beiträge veröffentlicht. Weiter so =)
Tolle Sendung – bringt wirklich Licht ins Dunkle dieser sehr verworrenen Thematik. Schade dass bei den ganzen Formaten und „Standards“ an zu vielen verschiedenen Strängen gezogen wird und ein Ende diesbezüglich nicht in Sicht ist.
Er hat Multicast gesagt!
Verstehe die Vorbehalte des Gastes gegen HTTP-Streaming nicht ganz. Im Gegenteil, es erscheint mir als die beste und portablste Lösung. Hoffentlich gibts bald viele clients! Nutzung der CDNs hat eigentlich nur Vorteile. Der Mehraufwand am Server ist vernachlässigbar, vergleichbar mit den Einsparungsmöglichkeiten durch Proxy, CDN, …, und das Argument Statistik und Co ist wirklich Humbug, – erstens lässt sich, wenn man wirklich access.log auswerten möchte, die betroffenen URLs ausschliessen, zweitens, wer ernsthaft seinen Traffic analysieren will, wird so und so auf etracker, google analytics und co setzen…
just my 0.2 cents
Also ich muss sagen, der MPlayer unterstützt bei HTTP-Streaming auch Sprünge. Ich verstehe nicht, warum man für Aufzeichnungen was anderes verwenden soll.
Ja super! Endlich gehts mit technischen Themen weiter. Darauf habe ich gewartet. Diese Sendung ist mal wieder klassisch CRE = Technik gut erklärt.
Weiter so.
Bin seit langem mal wieder enttäuscht von der Sendung. Trotz Hintergrundwissen hat Tim es nicht geschafft hier on-demand und live-Streaming vernünftig auseinanderzuhalten, auch wenn er zwischendurch mehrfach versucht hat die ganzen Fässer, die vom Gast aufgemacht wurden, auch mal zusammenzufassen.
Ständig Abschweifen zu Youtube und sogar iPhone mit zerhackten Dateien. Das ist alles nett, wenn man sich unterwegs was angucken will, aber es bleibt on-demand und nicht »alle gucken live das selbe«. Es wäre sehr schön gewesen hier deutlich mehr Klarheit reinzubringen.
Wenn ich nämlich nur ein mp3 oder nur ein Video auf mein Blog werfen will, dann ist das kein live-Streaming und dann brauch ich auch keinen dicken Streaming-Server für 5000 € oder einen selbstkompilierten http-Server, sondern ich pack nen in Flash gehackten Player zu meiner Datei und fertig ist die Laube. Das sieht dann für den Nutzer aus wie YouTube und der kann das anhören, während der Rest noch lädt, aber so aufwändig wie das im Podcast angedeutet wurde, ist das nicht. Ob man das jetzt progressive download nennt oder ob der Client da intelligent mp4-Dateien ansaugt oder ob man die vorher serverseitig stückelt, das ist das gleiche, weil alles nicht live und das ist technisch ein erheblicher Unterschied zu echtem live-Streaming.
Schade, dass das alles so sehr vermischt wurde. :-(
So, auch endlich mal die Folge angehört:
Ich muss LeSpocky leider ein Stück weit zustimmen, die Unterscheidung zwischen Live und On-Demand kam an einigen Stellen zu kurz. Vor allem, da für mich der Haupt-Einsatzzweck von Streams Live-Übertragungen sind; alles andere kann mein m.E. mit Progressive Downloads besser lösen.
Zum Schluss seid ihr dann glücklicherweise doch noch stärker auf den Live-Aspekt eingegangen.
Außerdem kam mir das ganze Audio-Streaming mit Icecast und Shoutcast zu kurz: Das Stichwort ‚M3U-Playlisten‘ fiel z.B. kein einziges Mal und wie genau Live-Streaming funktioniert, wenn per HTTP auf MP3i zugegriffen wird (die sich anscheinend ständig verändert?), ist mir auch noch etwas unklar.