GLS hat geschrieben:Zunächst mal verstehe ich diesen konstruierten Gegensatz "DVB-C vs. IPTV" nicht. IPTV kann man nicht einfach in ein Kabelnetz einspeisen, denn es ist kein Modulationsstandard, sondern eher eine Verbreitungsform oder wie auch immer.
Genau
das ist ja der Clou an der ganzen Sache. Während beim herkömmlichen Rundfunk eine gewisse Bindung vom Inhalt an den Übertragungsstandard besteht, hebt IPTV diese völlig auf: Das kann man über DSL, DOCSIS, FTTH, Mobilfunk, WLAN - einfach über jedes IP-fähige Medium - transportieren, weiterleiten, was immer man möchte.
Sieh es mal aus der Sicht von Vodafone: Die könnten mit IPTV dann nicht nur ihre Kabelkunden versorgen, sondern mit ihrem
einen IPTV-PoC die Programme auch DSL-Kunden, FTTH-Kunden und Mobilfunkkunden anbieten.
GLS hat geschrieben:Als muss man die IP-Streams auf Frequenzen draufmodulieren und da kommt man sehr schnell zu DOCSIS, das aber in der Version Euro und 3.0 exakt auf DVB-C1 basiert. Es ist de facto DVB-C! Alle unsere Modems sind nichts anderes als DVB-C-Tuner, nur mit dem Unterschied, dass man mit ihnen auch ins Netz senden kann. DOCSIS 3.1 verwendet wiederum sehr ähnliche, wenn nicht gar identische Modulationen wie DVB-C2.
Wenn man sich mal den Protokollstack (hier mal untypisch "kopfüber" dargestellt) anschaut, erschliesst sich der Sinn in der Tat nicht auf den ersten Blick:
DVB-C/C2
MPEG-2 Transport Stream -> PES -> Video/Audio/etc (herkömmlich)
DOCSIS 3.x
Ethernet (ggf. Multicast)
IP (ggf. Multicast)
UDP
RTP
MPEG-2 Transport Stream -> PES -> Video/Audio/etc (IPTV)
Also erst einmal nur 5 zusätzliche Protokollschichten, um eigentlich wieder auf das gleiche zu kommen. Nur muss man eben bedenken:
- DOCSIS ist das einzige MPEG-2 TS basierte Medium. Auf allen anderen (DSL, FTTH, Mobilfunk, WLAN) gibt es das nicht
- Man hat sich mit dem Aufwand eine Unabhängigkeit vom Übertragungsmedium geschaffen
- Man hat den Network Layer von IP hinzugewonnen, also die Möglichkeit, den Inhalt transparent über unterschiedliche Medien/Netze hinweg zu übertragen
- Man kann die Inhalte "on demand" statt nur statisch verbreiten
GLS hat geschrieben:Also heißt das, dass jedes IPTV, was ihr verbreiten wollt, zwingend über einen Broadcasting-Standard ins Kabelnetz eingespeist werden muss. Das Kabelnetz kann im Grunde nur Broadcast, auch wenn es wie oben in der DOCSIS-Beschreibung als "IP Multicast" bezeichnet wird. Das ist aber eher ein dynamisches Broadcast, denn Multicast verstehe ich als Möglichkeit, nur bestimmten Teilnehmern im Verbreitungsnetz einen Inhalt zu senden, aber nicht allen,
Nein, so funktioniert Multicast auch im LAN meistens auch nicht: Wenn man übliche Standard-Switches verwendet, die kein IGMP-Snooping machen, verbreiten die auch einen Multicast nicht selektiv, sondern an alle Ports.
Der Unterschied zwischen Multicast und Broadcast ist, dass der Multicast
angefordert wird, der Broadcast nicht. Wenn also ein "Spartenprogramm" vom niemandem im Kabelsegment geschaut wird, verbraucht es mit IPTV keine Kapazität - mit herkömmlichem Analog/DVB-C dagegen schon.
GLS hat geschrieben:Ein paar Fragen an die IPTV-Experten:
Im Thread ist außerdem die Verzögerung bei IPTV angesprochen worden. Wie ist es damit im Vgl. zu DVB (und ich meine nicht das Beispiel VDF/KDG mit der Reencodierung = lange Verzögerung)? Ist mit IPTV überhaupt "Live"-Fernsehen möglich?
Das ist eine Frage der Latenzoptimierung. In dieser Hinsicht wird vermutlich das alte "ungepufferte" Analogfernsehen in Verbindung mit terrestrischer oder kabelgebundener Verbreitung nicht mehr zu schlagen sein. Beim Satellitenfernsehen sieht es schon anders aus, denn da kann man viel Latenz (und Aufwand) sparen, wenn man die Satellitensignale nicht ins All sendet, um sie auf die Erde zurückzusenden, sondern sie direkt auf der Erde per Glasfaser verbreitet.
Beim digitalen Fernsehen gibt es zusätzliche Latenzen durch die digitale Videokodierung, durch Pufferung und ggf. durch Transkodierung. Bei IPTV kommen dann noch welche durch das Routing hinzu.
Dass IPTV anfangs noch das Nachsehen hat(te?) liegt daran, dass es als "Neuling" eben hinten angestellt wird: So wie auch einst erst das analoge Rundfunksignal erstellt wurde und erst daraus das digitale Rundfunksignal generiert wurde, wird/wurde das digitale Rundfunksignal noch einmal für IPTV transkodiert.
Wenn man mal dahin kommt, dass IPTV das "Primärsignal" ist, also die Sender ihre Programme gleich als IPTV erstellen, dann wäre das eben das "am meisten live" Signal, und ggf. daraus gewonnene Rundfunksignale würden nachlaufen.
GLS hat geschrieben:Wie ist es mit der Aufzeichnung von Streams? Beim DVB kann ich so viel gleichzeitig aufzeichnen, wie es meine Hardware (Tuner) hergibt. Über DVB-S kann ich alle 60+ Radiosender der ARD gleichzeitig aufnehmen mit nur 1 Tuner. Wenn ich mir 5 Tuner kaufe, kann ich auch 5 komplette Transponder/Kanäle mitschneiden, meinetwegen 5 mal 10 TV-Sender pro Kanal, also 50 Sender; die Festplatte würde dann natürlich glühen. Gibt es bei IPTV irgendwelche Beschränkungen? Klar werden das in der Praxis kaum welche machen, aber mir geht es um die Theorie.
Rein von den technischen Möglichkeiten her könntest Du alle IP-Multicast-Streams gleichzeitig anfordern. Dem kann bzw. muss bei DSL aber der Anbieter einen Riegel vorschieben. Die Telekom begrenzt z.B. bei VDSL-50 die Bitrate für IPTV-Multicast auf maximal 32Mbps, das reicht für 8 SD-Programme. Dieses relativ niedrige Limit dürfte aber eher der begrenzten Bandbreite von DSL geschuldet sein.
Bei Telekom-FTTH (auf GPON-Basis) sieht es schon anders aus, da werden die IPTV-Streams nicht einmal vom Bitratenlimit des Anschlusses abgezogen, d.h. man kann TV schauen und trotzdem noch mit 100 bzw. 200Mbps herunterladen - weil GPON wie DOCSIS ein "shared medium" ist und die Multicasts an alle Kunden im Gf-Segment gehen. Entsprechend würde ich beim "shared medium" erwarten, dass vielleicht die Anzahl der unterschiedlichen Multicast-Streams, die ein Kunde anfordern kann, begrenzt wird - dieser aber dennoch auch mehr empfangen kann, nämlich die, welche andere Kunden im Segment gerade anfordern...
GLS hat geschrieben:Dann kommen wir zum Umschalten/Zappen: Bei DVB-S und -C kann ich innerhalb von 0,5 bis 1,0 Sekunden von einem Programm zum anderen schalten. Wie schnell geht das bei IPTV?
Hängt vom "Reifegrad" ab: Bei "einfachem" IPTV, welches nur per Multicast einen "laufenden" Transport Stream anfordert, kommt erst einmal Latenz hinzu. Setzt man dann aber (netzseitig) einen "Puffer" drauf, welcher jeweils den letzten "Key Frame" (richtiger: I-Frame) des Videocodecs behält, und diesen auf Anfrage "beschleunigt" ausliefert, kann man damit das Key-Frame-Intervall des Videocodecs (was der begrenzende Faktor bei den Latenzen bei DVB-C/S/T ist) unterschreiten.
Die Telekom verwendet eine solche Technik bei ihrem IPTV, was aber in Praxistests nur 1x schnelles Umschalten ermöglicht, weil der Receiver dann eine "Mindestzeit" auf dem Programm verweilen muss. Das halte ich aber nicht für ein systeminhärentes Problem, sondern für eins der konkreten Implementierung der Microsoft-Software auf den Telekom IPTV-Receivern...
GLS hat geschrieben:Es sollte klar sein, dass ein zukünftiger TV-Verbreitungsweg mindestens denselben Komfort wie die aktuellen Standards bieten sollte.
Das ist dann aber "nur" noch eine Frage der Software, wobei die Fernseherhersteller allerdings nicht aus dem Knick kommen: Die sog. "Smart TVs" haben alle die notwendige Hardwareausstattung an Bord, um IPTV "gleichwertig" mit dem herkömmlichen Rundfunkempfang realisieren zu können - das dazu fehlende relativ kleine Stückchen Software implementiert aber keiner. Selbst die Nutzung von verschlüsselten Angeboten wäre schon gelöst, denn mit CI+ 1.4 ist auch vorgesehen, IPTV mit Steckmodulen zu entschlüsseln.
Dabei wäre es auch Sicht der Hersteller durchaus attraktiv, in künftigen Geräten auf die HF-Technik verzichten zu können und nur noch einen LAN-Port am Gerät zu haben. Ebenso wie es natürlich auch für die Nutzer schön ist, nur noch LAN oder WLAN zu benötigen und keine gesonderten Antennen oder Rundfunkleitungen mehr...