@yjogol,
die von Dir genannten Schritte erscheinen mir richtig.
Es bleibt dann die Frage wie weit man den normalen Zapping-Betrieb von Timeouts und Ähnlichem unbehelligt lassen kann, wenn man keinen VLC-Server hat oder dieser einfach aus ist.
Da mir die Vorgänge Dboxseitig kaum vertraut sind, muss ich mal nachfragen:
http-Streaming kann man hierfür so ohne weiteres nicht verwenden
upd-Multicast ist sicher die sinnvollste Lösung
Falls sich das auf den Teil
:sout=#duplicate{dst=std{access=http,mux=ts,dst=0.0.0.0:1234}}
am VLC-Server bezieht, also die Frage, ob der Server den Stream per http oder udp weiterleitet, so wäre das nicht richtig.
Eine Streamverteilung an die VLC-Clients per udp-Multicast schick den Stream an alle Netzwerkteilnehmer, egal ob sie es wollen oder nicht und damit auch an die Dbox zurück, wo der Stream eigentlich herkommt. Einmal hin und einmal her ist für die 10MBit-Halfduplex-Dbox leider zuviel.
Um die Dbox bei upd auszuklammern, muss man am VLC-Server alle gewünschten Client explizit angeben, also keine Multicast-Adresse als Ziel angeben, was das System unflexibel macht.
Streamverteilung über http belastet das Netzwerk weniger, da nur die Clients beliefert werden, die auch beliefert werden möchten. Die Dbox wäre somit vom sendenden Datenverkehr befreit und die Clients müssten dem Server nicht bekannt sein. Server- und clientseitig ist das die bequemste Variante.
Falls es sich auf den Transport von der Dbox zum VLC-Server bezieht, so ist das Obige weitgehend hinfällig, ausser in Netzwerken in denen mehrere Dboxen aktiv sind. Da würde die eine Dbox vom Multicast der Anderen belästigt werden. Umgehen könnte man das nur, wenn man die Dboxen in unterschiedliche Netzwerke setzt oder den Traffic filtert.
@seife,
die Idee auf Scripte zu verzichten und die Dbox zum Server zu machen hat duchaus ihren Reiz.
Solange es bei einem Client bleibt funktioniert das auch.
Wenn mehrere Clients das laufende Programm sehen wollen, wird das Dbox-Netzwerk sofort überfordert, sodass doch wieder ein Zwischen-Server mit mehr Kapazität erforderlich wird.
Die Sache mit dem Zapping-Event hätte sich dann aber dennoch erledigt, wenn sich für den direkten Client oder auch dem Zwischen-Server der Stream trotz Zappen seinbar nicht ändern würde.
@all,
ob irgendetwas davon Umsetzung findet, hängt vor allem davon ab, ob sich der Sache jemand ausführend annehmen wird. Derjenige wird es dann sicher mit dem Handwerkszeug machen, das ihm liegt.
Trotzdem sind alle Ideen natürlich gern sehen.
Gruß Frank
), sondern eine minimalversion von dvbstream ins zapit integrieren. Am besten so, daß die PIDs noch konvertiert werden, also beim Client immer PID 100=Video, PID 101=Audio oder so, dann kann man umschalten und der Client (MPlayer, xine) merkt gar nicht, daß sich das Programm geändert hat (und _muß_ das auch gar nicht merken, wichtig!
