Offene Runde: SAT>IP

Zitat von fnu

Nun, das ist richtigerweise ein Stream für ein Kanal, also relativ einfach für die Client Seite.

Beantwortet aber die Frage nicht ganz, nämlich die ob der SAT>IP Kopf dann in der Lage ist vom selben Tuner, der diesen Transponder gelockt hat, einen zweiten (dritten, vierten, ...) http Stream für einen anderen Sender auf diesem Transponder ausgeben kann ohne damit einen zweiten Tuner in dem SAT>IP Kopf zu befassen. Das kann der VDR ja schon lange, parallele Aufnahmen eines Transponders, wie auch andere STBs.

Das wäre eben die effiziente und intelligente Nutzung der Tuner im SAT>IP Server ...

Regards
fnu

Alles anzeigen

Mehrere http streams vom gleichen Receiver geht nicht. Mehrere rtsp streams bin ich nicht sicher, vielleicht sind auch hier nur ein stream (i.e. zwei ports) pro receiver möglich. Was problemlos mit rtsp möglich sein sollte ist z.B. ein kompletter Transponder in einem stream (laut c't etwa 40Mbit) zu einem client streamen, der dann die Kanäle auseinanderfummeln muss und dann entweder anzeigen, aufnehmen oder weiterreichen kann. Im Prinzip wie eine lokal angeschlossene DVB-S Karte. Das einzige was fehlt ist leider ein Treiber, der die API Aufrufe über rtsp weiterreicht unt den TS stream zurückgibt.

Sorry, aber wenn das so ist, dann hat sich "Sat2IP" doch faktisch gerade disqualifiziert. Faktisch werden hier Tuner ohne intelligente Nutzungsverteilung einfach "stur" auf Clients verteilt. Man muss also eigentlich genau so viele Tuner zentral vorhalten wie man auch direkt in die VDRs stecken würde.

Zitat von fnu

PS.: Und Full-Quotes sind irgendwie uncool ...

Ich bin froh, dass ich mit dem Tablet überhaupt tippen kann...

Zitat von fnu

Nun, da ich davon ausgehe, das der Stream nur die Information für genau diesen einen Sender enthält, hoffe ich das das noch nicht geht ...

Zitat von fnu

Ditto, der rtsp Stream enthält vmtl. ebenso nur die Bits des gewünschten Senders inkl. aller Neben-Informationen, z.B. Teletext, EPG ...

Ich glaube nicht, dass es mehr als einen http-Stream pro Receiver geben wird und auch rtsp-Streams wird es glaube ich nicht mehr geben, als Receiver da sind. Aber (wie gesagt, auf dem Tablet ist tippen nicht so einfach und mit zehn Fingern schaffe ich doch wesentlich mehr Text...) man gibt beim Aufruf an, welche PIDs man denn gerne hätte. Dass heisst nicht, dass ich jetzt entweder EINEN Kanal oder ALLE Kanäle streamen kann, sondern alles bis zu einem ganzen Transponder, d.h. von einer PID bis halt zu allen die auf diesem Transponder gesendet werden. Im Grunde genau wie bei einer lokal angeschlossenen DVB-Karte. Man tuned auf eine Frequenz, Polarität usw. und wählt aus, welche Program Streams zu einem Transport Stream multiplexed werden sollen. Clientseitig muss man dann natürlich den TS wieder richtig auseinandernehmen.

Zitat von fnu

Das wäre IMHO nicht cool, das würde im Prinzip schwächlich Clients wie z.B. Tabletts ja benachteiligen, was ja bei SAT>IP eben auch den Charme bringen würde. Ein dicker Stream würde alle Clients stark belasten.

Genau, wenn Du meinst, dass Deine Smartwatch nur die Untertitel verarbeiten kann, kommst Du vermutlich auch mit einer ziemlich langsamen Leitung aus...

Zitat von Mreimer

Man muss also eigentlich genau so viele Tuner zentral vorhalten wie man auch direkt in die VDRs stecken würde.

Ich glaube, Du solltest Dir mal die SAT>IP Spec ein wenig durchlesen. Ist wirklich sehr anschaulich und beschreibt das Konzept und die Implementierung sehr gut. In einem normalen Haushalt wirst Du aber auch mit einer intelligenten Tunerverwaltung immer mindestens so viele Tuner vorhalten müssen wie Du gleichzeitig unabhängige Clients erwarten kannst. Solltest Du aber eine Wohnanlage im Auge haben, dann ist SAT>IP genau das richtige, da Du dann Deine 50 Tuner fest auf jeweils einen Transponder schaltest und einfach jeden Kanal über Multicast ins Netzwerk streamst.

Gruß Darkstar

SAT>IP lässt durchaus mehrere Streams pro Tuner zu. Allerdings ist dann erstens das Setup komplizierter,
und zweitens muss der VDR wesentlich mehr an Management leisten.
SAT>IP muss in diesem Fall nicht als unicast sonderrn mittels RSTP und RDP im multicast mode arbeiten.
Dann können dynamisch PIDs zu einem Stream hinzugefügt und entfernt werden.
Dazu muss aber das Netzwerk IGMP-fähig sein!!

Dies ist definitv ein grösserer Software-Brocken, der da zu erstellen ist. Das IPTV-Frontend kann das so
nicht handhaben, da bedarf es eines dedizierten SAT>IP-Frontends mit multicast support.

Micha

Zitat von fnu

Ich weiß nicht ob SAT>IP das einschränkt, das die Kopfstation generell nur einen Stream pro Tuner abgreifen darf, soll, muß. Vmtl. hat von den Verantwortlichen nie jemand drüber nachgedacht ...

Hat sie tatsächlich nicht. Mein Fehler. Die Einschränkung gilt nur für http streams und wenn nicht generell, dann doch zumindest für den GSS-400.

Zitat von mikelh

SAT>IP lässt durchaus mehrere Streams pro Tuner zu. Allerdings ist dann erstens das Setup komplizierter,
und zweitens muss der VDR wesentlich mehr an Management leisten.

Das ist richtig. Laut Spezifikation ist die Anzahl der Clients abhängig von der Implementierung und große Server können theoretisch unbegrenzt viele Clients bedienen. Das Setup wird etwas komplizierter weil jemand die Verwaltung übernehmen muss. Meiner Ansicht nach ist das aber nicht der VDR, sondern ein DVB-Treiber. Für den VDR sollte der SAT>IP Server einfach über den Treiber eine Anzahl von DVB Devices zur Verfügung stellen, die genauso wie lokale Hardware angesprochen werden kann, da sie tatsächlich auch genauso arbeitet.

Zitat von mikelh

SAT>IP muss in diesem Fall nicht als unicast sonderrn mittels RSTP und RDP im multicast mode arbeiten.
Dann können dynamisch PIDs zu einem Stream hinzugefügt und entfernt werden.
Dazu muss aber das Netzwerk IGMP-fähig sein!!

Das ist nicht richtig. Multicast macht erst Sinn, wenn ich mit mehreren Clients tatsächlich den gleichen Stream beziehen möchte. Das ist z.B. dann der Fall, wenn ich für sehr viele Clients DVB Services bereitstellen möchte. Sobald die Anzahl der möglichen Clients gleich der Anzahl der (interessanten) Transponder ist macht es Sinn, einfach für jeden Transponder einen dedizierten Receiverkanal bereit zu stellen und dann sämtliche Kanäle auf dem Transponder als Multicast Stream allen Clients im Netz zur Verfügung zu stellen. Genau dann brauche ich auch eine entsprechende Netzwerktopologie, die intelligent den Client zu dem jeweils richtigen SAT>IP Server durchswitcht.

Zitat von mikelh

Dies ist definitv ein grösserer Software-Brocken, der da zu erstellen ist. Das IPTV-Frontend kann das so
nicht handhaben, da bedarf es eines dedizierten SAT>IP-Frontends mit multicast support.

Das ist das Problem. Meiner Meinung nach müßte dies ein SAT>IP DVB Treiber machen. Ob der dann auch Multicast berherrscht ist mir nicht so wichtig, Unicast würde mir schon völlig reichen. Leider fehlt mir das Know-How und die Zeit einen solchen Treiber zu implementieren. Hier wäre es schön, wenn die Hersteller von SAT>IP Servern sich zusammenschließen würden und einen Treiber für die aktuelle DVBAPI entwickeln (lassen) und bereitstellen würden. Bei Kosten ab 35 Euro pro Tuner gäbe es glaube eine ziemlich große Anzahl von Leuten, die sich sofort einen Server hinstellen würden um z.B. dem VDR im Wohnzimmer einen zweiten und dritten Tuner zu spendieren und aus der NAS im Arbeitszimmer einen Aufnahmeserver zu machen.

Hier nochmal der Link zur SAT>IP Spezifikation. Ist nicht sehr dick und wirklich sehr lesenswert.

Gruß Darkstar.

Hi,

ich versuche gerade den SAT>IP Server TSS400 mit VDR zum funktionieren zu bringen. Die channels.conf von Darkstar & wuselfuzz waren mir eine große Hilfe.
Was mich noch interessieren würde:

* Wie bekomme ich neue bzw. in der channels.conf nicht bekannte Sender in die Liste?
* Gibt es eine Möglichkeit, einen Scan auf den SAT>IP Server zu initiieren, um z.B. Hotbird Sender zu empfangen?

Grüße
Snorre

Zitat von snorre.snorre

* Wie bekomme ich neue bzw. in der channels.conf nicht bekannte Sender in die Liste?

Im Moment bleibt Dir nur eine vorhandene Liste aus dem Internet zu laden und zu konvertieren.

Zitat von snorre.snorre

* Gibt es eine Möglichkeit, einen Scan auf den SAT>IP Server zu initiieren, um z.B. Hotbird Sender zu empfangen?

Du könntest z.B. DVBViewer unter Windows nehmen und einen Transponderscan durchführen.

Schöner wäre natürlich ein echter DVB-Treiber, wobei ein solches Projekt bei mir leider am Know-How und Zeit scheitert.

Gruß Darkstar

.. rein interessehalber: wo liegt denn der Vorteil so eines SAT-IP Converters im vergleich zu einem VDR-Server im Keller mit zB. 4 Tunern? Mal abgesehen vom Preis?

Gute Frage aber führt vermutlich ins Off-Topic.

Nachteil, soweit ich das bisher überblicken kann: Man bekommt eine Black-Box ohne Quellcode. Weiterhin gibt es noch keinen "richtigen" Treiber für Linux. Wenn "intelligente Tunerbelegung" wirklich nur über Multicast geht, dann hat man zudem das gleiche Problem wie beim Netceiver (teure Switches, komplizierte Installation).

Vorteil dürfte der relativ günstige Preis sein. Und eben die Tatsache, dass man ein fertiges, funktionierendes, Gerät erwirbt. Ob man Stromverbrauch anbringen kann, weiß ich nicht. Es gibt auch sparsame PC-Hardware. Erst Recht wenn man "nur" streamen will und folglich mit schwacher Hardware auskommt.

Ich weiß nicht wie relevant der Standard wirklich ist, aber wenn sich das durchsetzt, dann könnte man einige der Nachteile wohl durchaus ausräumen. Gegen einen Open-Source Sat2IP-Server spricht ja erstmal nichts und einen Treiber könnte man z.B. mit CUSE durchaus umsetzen. Müsste halt jemand dran der wirklich weiß wie DVB tickt...

Man kann SAT>IP auch mit anderen Geräten bzw. anderer Software benutzen als mit dem VDR.
Ausserdem vereinfacht das die Hausverkabelung, man benötigt nach dem SAT>IP Konverter nur noch Netzwerkkabel.

Wenn Du allerdings sowieso schon 4 Sat Kabel an Deinem VDR liegen hast dürfte der Vorteil erst einmal etwas geringer ausfallen. Die Nutzung von SAT>IP dürfte aber flexibler sein als 1 VDR mit 4 Tuner und der Rest als streamdev Clients.

Hat das schonmal jemand versucht? Also wirklich nur LAN-Verkabelung und darüber den gesamten TV-Traffic mit fahren? Ist das praxistauglich auch dann wenn anderer Traffic dazukommt?

Ich würde mich nicht davon abhängig machen wollen und bei einem Neubau zumindest Leerrohre für Sat-Kabel vorsehen.

Erst Recht dann wenn ein Haus mehrere Stockwerke hat und zumindest rein theoretisch eine Untervermietung möglich wäre. Einen Mieter würde ich nicht ins LAN lassen wollen. Bei einer eigenen Sat-Verkabelung ist Mitnutzung der vorhandenen Antenne aber kein Thema.

Neubau Eigenheim kann man ja SAT Kabel verlegen, aber wenn man mit einem Bauträger eine Wohnung baut, sind SAT Kabel fast nicht mehr zu bekommen, ist zumindest meine Erfahrung aktuell.
Die wollen am besten nur noch KabelTV verlegen.

Ok, ich verstehe - der Unterschied zu einer VDR-Server-Lösung ist der "offene Standard", der dann am LAN-Kabel genutzt werden könnte - also von mehreren unterschiedlichen Geräten. Bei der VDR-Lösung bleibt man an den VDR bzw. XBMC (mit Plugin) und diversen anderen möglichen Applikationen "gebunden". Was ich aus dem Thread aber dennoch rauslese ist, daß es drzt. auch mit alternativen Clients noch nicht so gut läuft.
Wer wäre denn hier der richtige Ansprechpartner in "unserem Umfeld", der SAT>IP vornatreiben könnte - rofaror?

Ich halte das mal am Laufen - ist ja eine "offene Runde" lt. "Fredtitel"

Ihr sprecht hier von Treiber (im Kernel) für die "SAT-IP" Geräte (SAT zu LAN-Converter). Könnte dazu nicht auch UFO/O. Endriss ein Wort verlieren?

Sinnlos ist das Ganze doch, wenn hier "am anderen Ende" gebastelt wird - an der Ausgabe (Interpretieren der Streams (Control-/Data, etc) der verschiedenen Geräte)? Blöde Frage ?

Ist sehr interessant das Thema irgendwie ..

Zitat von Mreimer

einen Treiber könnte man z.B. mit CUSE durchaus umsetzen.

Wenn denn CUSE sinnvoll dokumentiert wäre..
Ich habe mal interessehalber vor einiger Zeit danach gesucht ohne Erfolg.

wuselfuzz hat vor einiger Zeit mal erste Schritte mit CUSE gemacht:
http://www.vdr-portal.de/board…-octopus-net/#post1166781