SAT>IP mit Billigreceiver+Recording Service und verschlüsselten Se

[markymark]

Hallo,

 

auch wenn zu SAT>IP hier schon einiges geschrieben wurde, kann ich doch nicht wirklich erkennen wie die gerade der Stand ist. Deshalb meine Frage:

 

Ich habe nen Recording-Service mit 4 Tunern, 2 Smartcards und MTD der mit mehreren DVBViewer Clients funktioniert.

 

Kann ich da heute schon nen SAT>IP-fähigen Receiver mit verbinden und auch verschlüsselte HD-Kanäle sehen, die über die Smartcards entschlüssel werden können?

 

... und falls, ja, was für Receiver haben sich da schon bewährt?

 

VG

MarkyMark

[nuts]

Nein das funktioniert nicht.

Der RS benötigt zusätzliche Parameter vom Sat>IP Client für die Entschlüsselung und die werden von den normalen Sat>IP Receivern nicht geliefert.

 

D.h. die verschlüsselten Sender bleiben dunkel.

Abhilfe muss Astra schaffen indem man sich mal zur serverseitigen Entschlüsselung äußert und diese in den Standard aufnimmt.

[Derrick]

 

Abhilfe muss Astra schaffen indem man sich mal zur serverseitigen Entschlüsselung äußert und diese in den Standard aufnimmt.

Ausser der (unbegründeten) angst vor SES hindert niemand die devs es aufzunehmen und zu implementieren. Muss nur einer mal damit anfangen

[nuts]

Also die Dev's der billig Receiver meinst du jetzt?

[Derrick]

..jeder PID lässt sich anfordern. Ich denke auch vom billigstreceiver

[nuts]

Nun der Server muss wohl wissen welche PID die PMT enthält und das übermittelt der Client mit den normalen Sat>IP Parametern nicht.

Also müsste der Receiver die proprietäre Erweiterung des Recordingservice implementieren, die nebenbei überhaupt nicht dokumentiert ist.

Am besten anschließend gleich noch die ebenso proprietäre Erweiterung vom Digital Devices Sat>IP Server ...

 

Würde mir das ja auch wünschen, aber viel Spaß das den Dev's der billig Receiver beizubringen.

Die größten Chancen hätte man da vielleicht noch bei den Dreamboxen, sollten die mal Sat>IP hinkriegen.

[Derrick]

Was redest du da? PAT ist immer PID 0 und da stehen die PMT_PIDs drin.

[nuts]

Ok da hab ich etwas die Begriffe verwechselt.

Hier hat Griga das Problem erklärt: http://www.DVBViewer.tv/forum/topic/54952-kathrein-ufsconnect-906-satip-unterstutzung-problem/?hl=astra#entry410975

[Derrick]

..macht nichts. Funktioniert ja doch (noch) nicht

[markymark]

Nein das funktioniert nicht.

Der RS benötigt zusätzliche Parameter vom Sat>IP Client für die Entschlüsselung und die werden von den normalen Sat>IP Receivern nicht geliefert.

 

D.h. die verschlüsselten Sender bleiben dunkel.

Abhilfe muss Astra schaffen indem man sich mal zur serverseitigen Entschlüsselung äußert und diese in den Standard aufnimmt.

 

Sind das nicht Informationen, die speziell der Recording-Service in Wirklichkeit trotzdem hat, weil er sie anderweitig braucht?

 

Kann man die dann nicht ggf. basierend auf Frequenz & Co noch schnell aus der Senderliste usw. des Recording Service beschaffen ?

[Derrick]

 

Sind das nicht Informationen, die speziell der Recording-Service in Wirklichkeit trotzdem hat, weil er sie anderweitig braucht?

Nein, hat er nicht. Er könnte sie sich aber einfach beschaffen.

[nuts]

Na dann lass mal hören Derrick.

[Derrick]

..steht alles in vorigen antworten

[Tjod]

Und auch wenn im RS mit viel Aufwand versucht würde zu erraten welchen, Sender der Client grade entschlüsselt haben möchte, würde das wahrscheinlich nur mit ganz wenigen Receiver mit irgendwelche Hacks funktionieren.

 

Da bei Sat>IP die Clients selber ihre Senderliste generieren. Und Wissen das Verschlüsselte Sender nicht gehen und die gleich beim Sendersuchlauf aussortieren.

 

Soll heißen das macht nur Sinn wenn es einen Standard gibt oder in Kooperation mit einem Hersteller der Clients.

Und das wird sicher nicht im Billig Segment anfangen wo der Verpackungshersteller gewechselt wird wenn dass ein andere 0,3 Cent pro gerät günstiger macht.

[Derrick]

Vielleicht meint der TE ja eigentlich auch was anderes..

 

 

Ich habe nen Recording-Service mit 4 Tunern, 2 Smartcards und MTD der mit mehreren DVBViewer Clients funktioniert.

 

Damit kannst du auch andere clients versorgen. Via upnp funktionieren mediaplayer, fernseher mit integrierten empfang von media servern etc.

Was der DVBViewer client sehen kann, kann man damit auch auf anderen clienten sichtbar machen einschliesslich verschlüsselter dienste. Hierbei gilt die gleiche einschränkung, die auch der DVBViewer unterliegt. Per CI/SC wird jewels nur ein service für einen client gleichzeitig entschlüsselt. Serverseitige teilung von ressourcen wie z.b. von tunern (beliebig viele FTA-dienste von einem transponder für beliebig viele clienten) gilt für CAMs nicht.

[markymark]

Und auch wenn im RS mit viel Aufwand versucht würde zu erraten welchen, Sender der Client grade entschlüsselt haben möchte, würde das wahrscheinlich nur mit ganz wenigen Receiver mit irgendwelche Hacks funktionieren.

 

Da bei Sat>IP die Clients selber ihre Senderliste generieren. Und Wissen das Verschlüsselte Sender nicht gehen und die gleich beim Sendersuchlauf aussortieren.

 

Soll heißen das macht nur Sinn wenn es einen Standard gibt oder in Kooperation mit einem Hersteller der Clients.

Und das wird sicher nicht im Billig Segment anfangen wo der Verpackungshersteller gewechselt wird wenn dass ein andere 0,3 Cent pro gerät günstiger macht.

 

Ich sehe die Probleme ...

 

Danke für die Info!

[nuts]

Gemeint war es so:

 

Man behält seine normale RS/DVBViewer Umgebung (inkl. CI/CAM usw.) und kann andere Teilnehmer über einen normalen Sat>IP Receiver (ohne HTPC) in sein Netzwerk aufnehmen.

Das hätte ich mir auch gewünscht, aber ohne die verschlüsselten Sender geht's eben nicht.

HTPC ist schon was schönes, aber doch etwas Overkill für Benutzer, die mit einem normalen DVB Receiver ausreichend versorgt sind.

UPnP, DLNA im Mediaplayer ist nicht wohnzimmertauglich für LiveTV!

[Derrick]

 

Man behält seine normale RS/DVBViewer Umgebung (inkl. CI/CAM usw.) und kann andere Teilnehmer über einen normalen Sat>IP Receiver (ohne HTPC) in sein Netzwerk aufnehmen.

Ok, dann wieder von vorne.. Ich bin dann allerdings der meinung, dass eher billigprodukte die serverseitige sperre umschiffen werden, da die hersteller sich doch keinen kopf um eine zertifizierung machen

[nuts]

Naja daran glaube ich ehrlich gesagt kaum.

Sowas funktioniert zwischen DD und DVBViewer, da man gute Kontakte hat und sonst eher gar nicht.

Wie soll das auch laufen? Der Dev vom billig Receiver schaut sich an was der DVBViewer so an den RS übermittelt und programmiert das nach?

 

Du könntest ja noch etwas ins Detail gehen wie man die "serverseitige sperre" abschaffen kann.

Lars, Griga und Manfred von DD haben wohl keine einfache/sinnvolle Lösung gesehen und sich für die Custom-Parameter entschieden.

[Derrick]

Du könntest ja noch etwas ins Detail gehen wie man die "serverseitige sperre" abschaffen kann.

 

Es heisst: Wo ein wille ist, ist auch ein weg. Wozu einen weg beschreiben, wenn der wille fehlt? Man muss sich natürlich auch nicht blindstarren auf's mauern beim DVBViewer. Kommt zeit, kommt rat, kommt oberrat

[Tjod]

Soll heißen es geht, wenn andere nur genug Zeit in was investieren, was sie vielleicht nicht wirklich interessiert und mit dem sie kein Geld Verdienen.

Aber obwohl es dich zumindest etwas zu interessieren scheint. Hast du keinerlei Interesse mehr Zeit zu investieren als zum schreiben von Polemischen Kommentaren nötig ist.

[Derrick]

Was heisst polemisch? Es gibt genügend threads, die belegen, dass man vor SES kuscht.

 

Es heisst, dass serverseitige entschlüsselung nicht gewünscht ist. Bei DD funktioniert im octopus net noch nicht mal MTD.

 

Für den server wäre es ein leichtes, die zur entschlüsselung notwendigen PIDs zu bestimmen, ohne zu raten. Getuned wird ein bestimmter transponder Der mux hat eindeutige service informationen, die zu den angeforderten PIDs gehören.

[Tjod]

Ich wüste jetzt kein Beispiel für deine Behauptung.

Das bei der ersten Implementation die im Auftrag von SES gemacht wurde alles nach denen Wünschen ging ist klar. Ich haben ja auch dafür bezahlt.

Und das wenn es einen Standard gibt man erst mal versucht es so Standard konform wie möglich zu machen ist auch klar.

 

Und das für Verschlüsselte Sender eigene Erweiterungen zum Standard entwickelt wurde widerspricht deiner Theorie sogar.

 

Du stellst dir Sachen wo du keinen überblicke drüber hast glaube ich viel zu einfach vor.

Wie willst du ohne einen großen Partner einen Standard erweitern oder gar einen eigenen entwickeln?

Rufst du die ODM persönlich an und überzeugst die davon? Oder überzeugst du ein paar Zehntausend Kunden davon bei den Markenherstellern anzurufen. So das die Marketingabteilung sich für den Standard einsetzt?

 

Ein paar Hundert Nutzer sind höchstens bei Teuren Geräten relevant (wo es sich einfacher umsetzen lässt, weil die Entwickler der Firmware zumindest Kontakt mit der Firma haben die es verkauft).

Und wenn da bei einem Hersteller genug Kunden nachfragen können die ja auf DD oder DVBViewer zugehen und eine der beiden Erweiterungen des Standards, die es ja schon gibt einbauen.

[blasgl]

Warte mal, ich hole mir Pop-Corn.

 

@Markymark: wenn ich einen billigen SAT>IP haben möchte, würde ich zu einem MiniPC tendieren.

http://geizhals.de/gigabyte-brix-gb-bxce-2955-a1037895.html?v=l

Da bleibst Du locker unter 200€ und hast SAT>IP "janz sicher"

[nuts]

Für den server wäre es ein leichtes, die zur entschlüsselung notwendigen PIDs zu bestimmen, ohne zu raten. Getuned wird ein bestimmter transponder Der mux hat eindeutige service informationen, die zu den angeforderten PIDs gehören.

Würde dir da vom Gefühl her zustimmen und dann müsste man auch den Standard gar nicht erweitern oder ähnliches.

Innerhalb der DVBViewer Familie könnten die Custom-Parameter ja auch bleiben.

 

Nunja Griga hat sich aber im verlinkten Thread recht eindeutig geäußert und ich glaube nicht, dass er damit vor SES kuschen wollte.

Also ein technischer Hintergrund den wir so eben nicht verstanden haben. Dafür spricht auch, dass sich DD für eine ähnliche Lösung entschieden hat.

 

Mein Fazit: Verbockt hat es Astra SES.

Edited September 5, 2014 by nuts

[Griga]

Derrick versteht schon sehr gut, wo das Problem liegt. Er will nur mal wieder etwas promovieren

[nuts]

Na dann.

Wenn jemand mal Zeit und Lust hat kann er das mir ja mal bei Gelegenheit in kurzen Worten erklären.

[Tjod]

Bei Sat>IP fordert der Client vom Server PID an und der Sat>IP Server sorgt davor dass genau die von der DVB Hardware an den Client weitergeleitet werden. Mehr weiß der Server nicht und um mehr muss der Sich auch nicht kümmern.

 

Wenn der Server jetzt an Hand der Daten erraten soll was der Client grade macht.

Also ob der grade einen Sendersuchlauf macht, irgend eine Art von EPG Daten einsammelt, ein Firmware Update emfängt, einen Sender eingestellt hat oder sonst was macht. Dann benötigt der deutlich mehr "Intelligenz".

Was dass ganze deutlich komplizierter macht.

Und Nur weil Senderliste/Senter Autoupdate usw. irgendwo anders im RS schon vorhanden sind heißt das noch lange nicht das sich das da einfach wiederverwenden lässt. Und bei der viel zahl der Clients die alle ihre anfrage etwas anders gestalten, müsste man sicher recht lange mit verschiedener Hardware Testen bis das wirklich zuverlässig ist.

 

Theoretisch ist dass sicher möglich, aber dass kann viel Zeit kosten und wenn das niemanden der die Zeit selber investiert Persönlich wichtig ist. Oder jemand anderem viel Geld wert ist (bezahlen der Arbeitszeit und gegebenenfalls der Hardware zum Testen) ist es eher unwahrscheinlich.

 

Das ganze muss man ja auch nicht unbedingt im RS man könnte das auch als Sat>IP Proxy realisieren. Der die Steuerkommandos von einem Receiver auf einem Port empfängt, analysiert und um die zum entschlüsseln notwendigen Parameter auf einem anderen Port an den RS weiterreicht. Und wenn es auf einem anderen PC laufen soll z.B. für den DD Server. Müssten die restlichen Pakete einfach nur weitergeleitet werden.

 

Und dass ganze nur um die zum entschlüsseln Notwendigen Informationen zu ermitteln. Die der Client leicht dem Server mitteilen könnte.

 

Aber damit Receiver das einbauen muss dass entweder in den Standard. Oder ein großer Anbieter muss die Funktionalität in seinen Server einbauen.

Solang das nur in Nischenprodukten wie dem RS oder denen von DD existiert. Interessiert das keinen großen Hersteller.

 

Bei kleinen Herstellern mit eigener Entwicklungsabteilung kann man vielleicht Glück haben. Wenn genügend Kunden anfragen.

 

So weit die Situation wie ich sie verstanden habe.

[hackbart]

Tjod hat das ganz gut zusammengefasst und da ich ab und zu auch via Mail Anfragen bezüglich Sat>IP bekomme werde ich in so einem Fall wohl auch auf diesen Thread verweisen.

Also kurz von unserer Seite in 2.5 Zeilen zusammengefasst:

 

Der Recordingservice kann als Sat>IP Server dienen und tut er auch bei vielen Nutzern. Was aber nicht geht ist das PayTV auf dem Server entschlüsselt und zu einem x-beliebigen Client unverschlüsselt übermittelt wird. Zwar kann der Recordingservice das und ebenso auch die Server von Digital Devices, brauchen aber zusätzliche Informationen die für eine Dekodierung notwendig sind. Das wird aber in der Form niemals in die offiziellen Spezifikationen eingebaut werden.

Für den Endkunden ist das zwar "doof", aber die Content-Anbieter bezahlen den Platformbetreiber und frei nach Marin Luther: Wessen Brot ich ess, dessen Lied ich sing Übrigens Die sind die Autoren der Sat>IP Spezifikation auch nicht von "Dummsdorf" und wissen dies alles sehr wohl.

 

Christian

[Derrick]

Mehr habe ich ja auch nicht geschrieben, allerdings verbietet niemand, die notwendige information zu ergänzen und zwar mit ganz einfachen standardbefehlen..

[hackbart]

Stimmt und soweit wie ich weiß wird so etwas auch nicht kategorisch ausgeschlossen. Es ist halt nur nicht definiert und wirds auch nicht. Davon abgesehen sind die derzeitigen Serverlösungen eh nur eine Notlösung bis Sat>IP LNBs angeboten werden.

[Derrick]

Es ist halt nur nicht definiert und wirds auch nicht.

 

ähem, DD hat doch schon in zusammenarbeit mit DVBV das proprietäre x_PMT eingeführt und jede bessere plugin fordet auch die für irgendwelche zwecke notwendigen infos an

[hackbart]

Ich rede von SES die die Sat>IP Rahmenbedingungen über ihre Spezifikationen und Zertifizierung abgesteckt haben.

[nuts]

In den normalen Receivern wird sicherlich nichts ergänzt und die Entschlüsselung mit dem RS möglich zu machen.

Also kommt dazu etwas in die Spezifikationen (lt. Christian wohl nicht) oder der RS kommt mit dem klar was die Clients liefern (wohl auch nicht).

 

Fazit: nichts funktioniert wie es soll!

Täterschaft: Astra

Und dann noch gleichzeitig HD+ pushen ... also das kommt mir schon vor wie aus "Dummsdorf".

[Derrick]

Wenn jetzt noch HD+ bashing dazu kommt, sollten wir die diskussion besser vertagen, bis es was neues zu berichten gibt...

[nuts]

Das ist kein HD+ Bashing.

Verstehe nur nicht wieso man einen Sat>IP Standard rausbringt und das eigenen PayTV Angebot dann davon ausschließt.

[Tjod]

Es gibt SAT>IP Receiver zumindest mit CI+ Schacht. Das schließt sich nicht gegenseitig aus.

Aber grade HD+ schlisst es aus dass die Entschlüsselten Daten, einfach an andere Geräte weiter gegeben werden.
Wenn eine weitergrabe erfolgt müssen die Daten vorher wieder verschlüsselt werden. Und es muss sicher gestellt werden dass sich der Client an die HD+ vorgaben hält und die Daten selber auch absichert.

Aus der HD+ Sicht macht es Sinn die Daten erst so spät wie möglich zu entschlüsseln. Am besten erst im wiedergebe gerät. Weil man sonst in der ganzen kette davor die Einhaltung DRM sicherstellen muss.

(Um Kundenfreundlichkeit geht es bei allem was sich um DRM (Digitale Beschränkungsverwaltung) dreht nie.)

[Jumpanino]

Ich habe das Thema hier mal etwas mitverfolgt. Aus meiner Sicht kann der RS Pay-TV schon unverschlüsselt senden. Ich empfange z.B. Live-Pay-TV vom Server mittels eines PC´s mit DVBViewer als client. Ich muss am Client nicht extra ein Plugin benutzen. Wobei ich das tue, das hat aber einen anderen Grund. Und ich empfange Live-Pay-TV auf dem Handy mittels VPlayer. Daher müsste das doch dann auch mit anderen Client-Lösungen gehen. Genauer... Der angeforderte Sender wird im RS entschlüsselt und unverschlüsselt übers Netz geschickt. Oder irre ich mich da nun?

[Tjod]

Ja dass geht theoretisch, aber das Problem ist das der Client weitere Parameter an den Server schien muss, die im Sat>IP Standard nicht definiert sind.

 

Das heißt der Hersteller von dem Client müsste sich an die DVBViewer Entwickler und/oder Digital Device wenden. Das sind die Hersteller der beiden Sat>IP Server die das Serverseitige entschlüsseln können und entsprechende Erweiterungen für Sat>IP definiert haben.

 

Ich glaube aber kaum dass das ein Receiver Hersteller macht.

Aber du kannst gerne versuchen die Hersteller davon zu überzeugen sich zu melden und die Erweiterungen in ihrem Produkt einzubauen.

 

 

Und bevor die Frage kommt ob das auch geht ohne dass die Receiver Hersteller aktiv werden müssen. Das habe ich hier schon beschrieben.