bertibott
Goto Top

Quellenspezifische Multicastgruppen

Hallo,
ich beschäftige mich zur Zeit (noch sehr theoretisch) mit dem Einsatz von Netzwerktechnik in Videoproduktios- oder Broadcastumgebungen.
Grundsätzlich ist die Idee einfach: Wir ersetzen die bisherverwendete Videotechnik (SDI-Kreuzschienen und Koaxialkabel) durch IT-Technik (Swicthes/Router und CAT-6/7 Kabel).
Wir gehen mal davon aus, dass der Schritt von einem SDI-Signal zu einem UDP-basierten Stream funktinoiert.
Verteilen wollen wir unsere Signale per Multicast.

Ein Sender sendet an eine Multicastgruppe und ein Empfänger abnoiert die Gruppe wenn er den Stream haben will... Im Grunde ist die Welt in Ordnung... solange bis, aus welchem Grund auch immer, zwei Sender an die selbe Gruppe senden.

Mich würde interessieren wie ich diesen Fall abfangen kann. Wenn ich das richtig verstanden habe gibt es SSM, das genau dafür sorgt, dass nur ein Sender pro Spannbaum senden darf.
Was genau heißt das? Kann ich in meinem Netzwerk mehrere Spannbäume haben? Dürfen die sich überlappen? Kann ich den Sender eines Spannbaums ändern?

Das angedachte Szenario hat aber grundsätzlich nicht immer nur eine aktive Quelle. Sondern viel Quellen und viele Senken.
Bsp: Vier Kameras. Alle gehen einmal auf einen Kontrollmonitor und in den Bildmischer. Zusätzlich haben wir drei Mikrofone für drei Sprecher (in drei Sprachen). Die gehen aber nicht direkt auf die Sendesumme sondern werden voher durch das Soundprocessing geschoben und nacher wieder mit dem Videozusammengführt.

Kann ich das ganze mit SSM erschlagen?

Content-Key: 393986

Url: https://administrator.de/contentid/393986

Printed on: April 29, 2024 at 03:04 o'clock

Member: GrueneSosseMitSpeck
GrueneSosseMitSpeck Nov 28, 2018 updated at 14:12:56 (UTC)
Goto Top
ich empfehl dir zum einen mal Hintergrundrecherche.... was für ein Videomaterial wird da geschnitten? Du schreibst da was von Produktion. Die endgültige Kompression des Videostreams geschieht erst im Nachgang.

Beim Abmischen von Life-Videomaterial braucht es Bandbreite... viel Bandbreite.

Mit 1 GBit Ethernet kommt man zumindestens mal beim Versand von Video im Rohformat - wie es im Videoschnitt üblich ist - nicht allzu weit. 1080i50 kommt mit einer Farbreduktion auf 4:2:0 mit weniger als 1 GBit aus, 1080p50 4:2:0 wird mit 1,5 Gbit gerechnet, die 4k Formate sind je nach Farbtiefe mehr oder weniger knapp unter 10 GBit angesiedelt, aber bei 4kp50 und 8 Bit pro Farbe komm ich schon auf 4,8 GBit pro Sekunde, für HDR wird auch in 10 Bit gerechnet. was den Durchsatz ncoh mal deutlich erhöht. Also besser gleich mit 10 GBit rechnen, für 8K und HDR ist das schon wieder zuwenig...

Aus diesem Grunde haben all die Videoproduzenten noch so lange am 1080i50 Format festgehalten, weil sie in 1 GBit Technologe im Videoschnitt gesetzt hatten, und schon 1080P50 nicht konnten. Aber Interlace ist ja eh Schnee von gestern.

Ansonsten - die Multicast Gruppen sind eigentlich so definiert: alle Teilnehmer senden einen Group join an die 224.0.0.22 und teilen die Portnummer mit, der Switch routet den Datenverkehr nach dem Prinzip alle Teilnehmer an alle Teilnehmer, und für UDP forwarding über mehrere Switche gibts modellspezifische "Multicast manager" Software, die man meist dazukaufen muß und da kann man das dedizierte Multicast Management einstellen, ansosnten routet ein Router das nach RFC, sprich an alle Teilnehmer einer Group bis ein Teilnehmer ein Group leave sendet.
Member: bertibott
bertibott Nov 28, 2018 at 14:26:26 (UTC)
Goto Top
Was nun genau übertragen wird ist für mich im Moment eigentlich zweitrangig. Es geht darum ein Studio/Produktionscenter mit den Standards SMPTE 2022 bzw SMPTE 2110 zu realisieren. Bzw darum wie das Netzwerk für einen solchen Aufbau aussehen müsste. Das man mit einem Büroswitch nicht weit kommt ist mir auch klar... In meinem Testaufbau verwende ich einen SN2100 von Mellanox der laut Handbuchauf allen 16 Ports 40GBit verarbeiten kann.

Meine Frage zielt darauf ab wie ich das Problem, dass zwei Sender auf der selben Leitung senden abfangen kann.
Normalerweise sollte es dazu nicht kommen... aber Fehler passieren ja...