Überwachung von Fernsehen - IPTV
Wer eine IPTV Plattform anbietet, muss sie auch überwachen. Nur ist das nicht ganz so einfach, wenn nicht alle Komponenten aus einer Hand kommen. Wir standen vor der Aufgabe, an einer Zwischenstelle am Transportweg, die Qualität der Aussendung monitoren zu müssen.
Kurze Ausfälle
Das eigentliche Problem beim Fernsehen besteht darin, dass jeder auch noch so kurzfristige Ausfall vom Kunden bemerkt wird und instantan zu Störungsmeldungen führt.
Um schnellstmöglich von einem Problem zu erfahren, sollte also das Ausbleiben von Multicast-Paketen für eine bestimmten Sender nach wenigen Sekunden zu einem Alarm führen. Die Hotline muss also beim Entgegennehmen der Störungsmeldung bereits wissen, welcher Sender gerade kein Bild liefert. Dafür hat sie maximal fünf Sekunden Zeit.
Was wir also getan haben, ist einfach: Auf einem altersschwachen Rechner werden sämtliche Kanäle abonniert (macht nicht ganz ein Gigabit voll) und notiert, welcher Sender zuletzt ein Datenpaket abgeliefert an. Fehlen Daten für mehr als die definierten fünf Sekunden, wird protokolliert wie lange schon von welchem Streamer die Daten fehlen. Das füttert direkt das Alarmsystem. Und natürlich kann man dies auch auf malen (logarithmisch, um die kleinen Ausfälle nicht zu übersehen):
Ein zweites Ergebnis dieses Monitorings ist die Erkenntnis welcher Streamer noch wie viele Kanäle ausliefert. Fällt dieser Wert auf Null, ist dringender Handlungsbedarf gegeben, weil offenbar eine Komponente total ausgefallen ist. Man kann also sofort eine SMS an die Bereitschaft verschicken.
Details
Es stellt sich aber heraus, dass die Qualität eines Fernseh-Erlebnisses nicht allein von der Existenz eines Bildes abhängt (und vom Programminhalt), sondern auch von den Störungen, die das Bild überlagern oder unbrauchbar machen.
Die Software wurde also um die Fähigkeit erweitert, in die MPEG-TS Daten hineinzuschauen. Dies gibt eine Menge von interessanten Informationen:
Datenstrom liegt von a.b.c.d an. Statistik über 3 Sekunden: Empfangene UDP Pakete 3446 Paket zu kurz 0 Verarbeitete MPEG Pakete 24122 Fehlende Sync-Markierung 0 Statistiken pro Datenstrom (MPEG-Programm) Programmkennung (PID) 6630 6610 6622 6620 6621 6600 0 32 19e6 19d2 19de 19dc 19dd 19c8 0000 0020 Empfangene Pakete 56721738 865 494 377 29 28 24 verschluesselte Daten 021366 829 448 331 0 0 0 Ansetzpunkte, FullFrames 0 5 18 23 23 0 0 0 priorisierte Daten 0 5 0 0 0 0 0 0 Signalstoerung am Streamer 0 0 0 0 0 0 0 0 Taktstoerung am Streamer 0 0 0 0 0 0 0 0 Sequenzfehler(CC) 0 0 0 0 0 0 0 0 Abweichungen vom Synchronisationstakt 19d2 (absoluter Jitter) 26% || 20% || 14% |||| 8% |||||| 2% |||||| +---------------------------------------------------------------------- ms 0123456789012345678901234567890123456789012345678901234567890123456789 0 1 2 3 4 5 6 Abweichungen der Paketankunftszeiten (relativer Jitter) 66% | 52% | 37% | 22% | 7% || |||| +---------------------------------------------------------------------- ms 0123456789012345678901234567890123456789012345678901234567890123456789 0 1 2 3 4 5 6 Kanal ist durch Kunden im Moment abonniert.
Wie für einen HDTV Kanal üblich ist die Datenrate hoch und der Jitter klein. Beim einem Radioprogramm sieht das anders aus:
Datenstrom liegt von a.b.c.e an. Statistik über 3 Sekunden: Empfangene UDP Pakete 43 Paket zu kurz 0 Verarbeitete MPEG Pakete 301 Fehlende Sync-Markierung 0 Statistiken pro Datenstrom (MPEG-Programm) Programmkennung (PID) 851 0 850 0353 0000 0352 Empfangene Pakete 282 13 6 verschluesselte Daten 0 0 0 Ansetzpunkte, FullFrames 0 0 0 priorisierte Daten 0 0 0 Signalstoerung am Streamer 0 0 0 Taktstoerung am Streamer 0 0 0 Sequenzfehler(CC) 4 0 4 Abweichungen vom Synchronisationstakt 0353 (absoluter Jitter) 59% | 46% | 33% | 19% | 6% | | | | | || || || | || | | +---------------------------------------------------------------------- ms 0123456789012345678901234567890123456789012345678901234567890123456789 0 1 2 3 4 5 6 Abweichungen der Paketankunftszeiten (relativer Jitter) 15% | 11% | 8% | | | | 5% | | | | | | || | 1% | || ||| |||||||||||| || | | | +---------------------------------------------------------------------- ms 0123456789012345678901234567890123456789012345678901234567890123456789 0 1 2 3 4 5 6 Kanal ist durch Kunden im Moment nicht abonniert.
Ein MPEG-Transportstrom (ein Programm im Fernseh-Sinne) besteht aus vielen Programmen (im MPEG-TS Sinne), die oben alle tabellarisch aufgelistet sind. Das Programm 0000 ist ein Indexkanal, der festlegt, welcher anderen Programme die Sendung ausmachen und wie sie zusammen spielen. Aber auch ohne diese Detailkenntnis kann man erraten, dass der höchstbandbreitige Anteil die Bildinformation sein wird. Weitere Programme sind Teletext, Untertitel, EPG, einer oder mehrere Audiokanäle. Besonders viele dieser Programme hat ZDF-HD.
Statistik
Diese kurzen Einblicke kann und sollte man auch graphisch aufbereiten, denn oft ist es erst nach dem Vorfall (wie oben aufgezeigt) möglich, sich um die Ursachen kurzer Ausfälle kümmern zu können. dazu braucht man historische Daten.
Um nicht zu viele Daten zu generieren, wird aktuell über eine Minute summiert und so pro Minute und Programm (im MPEG-TS Sinne) ein Messwert generiert. Diese lassen sich dann plotten.
Zuerst einmal die Datenrate als Pakete * Datengröße / Zeit. Man sieht schön, wie das Bildsignal eines HD-Kanals die Bandbreite dominiert.
Interessant ist der Einbruch zwischen 17:30 und 20:00. Das Signal war kurz weg, kam dann mit halber Bandbreite wieder. Eine mögliche Erklärung ist, daß der Sender hier eine Sendung in SDTV eingeschoben hat, die aus einer Fremdquelle konvertiert wurde.
Einige Sender, vor allem die dritten Programme übernehmen zeitweise den kompletten Datenstrom von der ARD. Man sieht deutlich den Wechsel der Programm-Nummer.
Zurück zum Fehler an dem bewussten Abend. Die Anzahl der Full-Frames, also der Wiederaufsetzpunkte für das Bild bzw. die anderen Kompressionsverfahren gibt Aufschluss, ob eine Störung im Netz oder beim Sender vorliegt. Eine Netzkomponente wird üblicherweise nicht das Signal transkodieren und eigenständig Aufsetzpunkte einstreuen:
In dem fraglichen Zeitraum hat also der Sender immer wieder versucht, sein Signal zu resynchronisieren. Natürlich auf einem wesentlich niedrigerem Level als wenn ein HD-Datenstrom abliegen würde. Interessant ist aber auch, wie andere Programme mit erheblich mehr Aufsetzpunkten versorgt werden.
Es kann natürlich sein, dass der Streamer selbst kein Signal anliegen hatte. In dem Fall signalisiert er diese Information mit, um eine komplette Neusynchronisierung des MPEG Programms zu erzwingen.
Es ist deutlich zu erkennen, dass der Streamer zu Beginn der Störung nicht ausreichend neue Information erhalten hat. Die Effekte, die sich dann hinzogen sind aber nicht mehr an dieser Stelle zu suchen.
Eine zweite Fehlerquelle liegt auf Seiten der Sendeanstalt. Die Programme sind untereinander mit einem 33MHz Takt synchronisiert. Dies stellt sicher, dass Bild und Ton nicht auseinander laufen. Der hohe Takt eignet sich auch zur Taktregeneration und -kalibrierung an der Empfangsstelle, wenn dort keine stabilen Quarze vorhanden sein sollten. Trotzdem muss ab und zu dieser Taktquelle getauscht werden. Dann sendet die Anstalt eine entsprechende Markierung, um auch diese Synchronisation neu zu erzwingen.
Auch hier ist deutlich, dass diese Taktinformation schon senderseitig zu den Ausfallzeiten auftrat. Ein Fehler auf Seiten der Netzplattform ist damit eigentlich auszuschließen.
Was aber im Netz auftreten kann sind Paketvertauschungen und -verluste. Diese äußern sich in Fehlern an den Sequenznummern (die allerdings nur zyklisch von 0 bis 15 laufen).
Interessant an diesem Bild sind die kleinen CC-Fehler im Bereich nach 18 Uhr. Hier werden die Datenpakete immer wieder mit Verlusten oder vertauscht beobachtet. Ein Grund könnte sein, dass die Programme vom Sender immer wieder neu synchronisiert werden. Dann kann auch der Sequenzzähler zurückgesetzt werden, was hier offenbar der Fall ist.
Zum Schluss noch ein Blick auf den mittleren Jitter.
Keine weiteren Fragen.
Fazit
Man kann einige hundert Sender ohne extra teure Technik monitoren. Man muss es nur tun.
Freundliche Grüsse
BeoService
thank you for the document published. I am curious to know the name of your software and the current status of it.
We have a new IPTV service deployed, and we are searching ways to monitor it.
Best
3 Kommentare