[HOWTO] Netceiver im externen Gehäuse, Infos zum Netceiver

Nano:

AFAIK geht mit der mcli-Lib alles, das winfuse war aber Wuschelstudio 2008.

@ Razorblade:

> sw anstatt das Netceiver-Protokoll auf DVB-IPTV umzustellen

a) gabs zur Beginn der NetCeiver-Entwicklung (Ende 2006) DVB-IPTV noch nicht mal als Draft.
b) Ist DVB-IPTV ein Riesenmoloch basierend auf UPnP, in dem von den üblichen Verdächtigen jeder sein Misthäuflein hinterlassen hat. DVB-IPTV ist höchstens für den Client halbwegs effizient handelbar, aber der Serverteil ist heftig. Mit PC ist das alles keine Kunst, der NetCeiver hat aber eine 66MHz CPU mit 33Bogomips. Da wäre das UPnP-Gefummel von DVB-IPTV ein Killer. Es geht hier darum, die volle DVB-Funktionalität mit möglichst billiger HW übers Netzwerk transparent machen zu können. Wir wollen eben keinen PC dafür, da wäre es auch recht schwer/teuer, 6 Tuner reinzubekommen...

> Ob man nun auf IPv6 oder IPv4 Multicastet sollte ja keinen Riesenunterschied machen

Oh doch. Das ist nämlich genau der Witz am NetCeiver-Konzept. Es werden keinen fertigen gemultiplexten TS-Streams mit VPID, APID & Co (ein "Programm") auf einer Multicast-Adresse gesendet, sondern jede PID hat eine eigene Adresse, die aber ohne jede zentale Verwaltung "errechenbar" ist.

Fürs Tunen gibt es auch kein umständliches XML-Gewurschtel. Der Gag ist, dass der Client per MLDv2 eine NOCH NICHT VORHANDENE IP6-Multicast-Gruppe abonniert, die in der IPv6-Adresse die GESAMTE INFORMATION zum Tunen beinhaltet (Satpos, Frequenz, Modulation, SR, PID,...). D.h. erst der erste Request einer MCG löst im NetCeiver das Tunen aus und knippst die verlangte PID an *). Erst danach existiert die Multicastgruppe mit Paketen wirklich. Das MLDv2 wird also völlig standardkonform aber "unerkannt" für normale IP6-Multicast-Router benutzt, um eine Information zum NetCeiver zu tunneln. Wir müssen also nicht zwei Protokolle fürs Tunen und fürs MC-Snooping machen, es geht alles in einem. Und das vor allem auch schnell... Schau mal bei neueren NC-Firmwares auf die hintere LED zwischen Tunern, wenn der vdr einen EPG-Scan macht. Das Geflacker ist die Rate, mit der neue MCG-Requests eintrudeln...

*) Der NetCeiver macht das völlig in HW. Die 6TSe aus den Tunern laufen über vollständige PID-Filter (d.h. jede beliebige PID in beliebiger Anzahl), werden anhand gleicher PID zu grösseren Paketen zusammengebaut, um die MTU auszunutzen, dann wird das Ding samt individuellen IPv6-Header zur Netzwerkkarte geschickt. Bei dem gesamten Sende-Vorgang macht die CPU im NetCeiver nichts, das geht an der völlig vorbei. Die managed "nur" die PID-Filter und kümmert sich ums Tunen und die MCGs. Nur so geht es, mit wenig CPU-Leistung problemlos mehrere 10MByte/s und viele PIDs ins Netzwerk zu blasen.

BTW: Es gibt schon Vorkehrungen, die Netzwerk-Engine auf IP4 zB. für UPnP umzubauen. Da müsste das XML-Gefummel aber ein PC erledigen, der dann auf den NetCeiver als RTP-Quelle verlinkt. Dauert aber alles noch, zuerst kommt mal das neue CAM-Handling in zwei Stufen. Die zweite wird sicherlich etwas überraschend

schorsch: Sind ja interessante Hintergundinfos. Bevor Du jetzt etwas in den falschen Hals bekommst, ich finde der Netceiver ist ein geniales Produkt und die technische Umsetzung ist nicht nur elegant sondern auch effizient.
Trotzdem würde ich gern das Thema IPTV etwas weiterdiskutieren

Wenn ich mal in die DVB-IPTV Specs (v1.4 Stand 07/09) schaue, dann finde ich dort UPnP nur im Zusammenhang mit dem Endpunkt (HNED) und AutoIP, aber nicht im Empfang, der läuft (sehr ähnlich dem was der Netceiver macht) über IGMP und abonnieren von Multicast-Gruppen. Der Hauptunterschied ist, dass das "Delivery Network Gateway" nur vordefinierte Sender announced, ebenfalls über eine Multicast-Gruppe nachdem sich ein Endpunkt angemeldet hat indem er der Gruppe beigetreten ist.
Wenn man jetzt auf dem Netceiver eine statische "Kanalliste" vorhält die nur bestimmte Sender bewirbt (per Multicast oder sogar Broadcast), anstatt alle möglichen Frequenzen/PIDs verfügbar zu machen sollte das doch keinen wesentlichen Zusatzaufwand für den Netceiver bedeuten oder? Sobald dann ein Client einen Sender requested macht man genau das was jetzt auch schon gemacht wird, aber schickt es über einen IPv4 Multicast.
Man könnte theoretisch sogar aufs PID Filtering verzichten und den ganzen TS übers Netz schicken, das hätte den Vorteil, dass zusätzliche Endpunkte ohne dass erneut getuned werden muß andere Teilnehmer sofort den gleichen Stream (ggf mit anderen PIDs) empfangen könnten, aber das das wäre nur ein netter Nebeneffekt.
Ansonsten halte ich es gerade bei mehreren (vielen) Endpunkten für sinnvoll die "Senderliste" an einer zentralen Stelle vorzuhalten und die Clients nur noch einen von dieser Liste zu requesten.
Klar, man müßte sich noch überlegen, wie man aktualsisierte Kanallisten auf den Netceiver bekommt, aber das kann ja kein Hexenwerk sein.

So genug Wunschkonzert, aber ich schätze ich habe mit meinen 3 vdr's (zwei reine Frontends für Live-TV und Replay und ein reiner Recording-Server) auch nicht gerade das üblichste Setup...

Gruß,
Razor

Nano:

Der Code im dvbfuse ist etwas komplizierter, weil er selbst die SI parsed (um alle wichtigen PIDs rauszufinden) und eine synthetische PAT einbaut, eben genau um den Playern etwas nachzuhelfen. Die PMT wird vom Sender selbst genommen. Dazu gibt es eine Statemachine in mcli_handle_ts. Im Prinzip müsstest du den Fuse-Code rauswerfen, das mcli_handle_ts füllt "nur" einen Ringbuffer, den man anderweitig verwenden kann.

Razorblade:

Das Senden von Programm-Multicasts in HW ist ziemlich aufwendig. Dazu braucht es für jede PID eine Art ID, zu welchem Programm die PID gehört. Anhand der ID muss dann der passende IP-Header mit Zieladdresse zusammengebaut werden. Das muss ja alles "on-the-fly" in HW passieren. Theoretisch kann es auch passieren, dass eine PID zu zwei verschiedenen Services gehört. Dann müsste man ein Packet hintereinander an verschiedene Adressen schicken.

Und dann gibt es noch das Problem, den RTP-Sequence-Header für jede Verbindung zu managen...

> Man könnte theoretisch sogar aufs PID Filtering verzichten

Von 6 Tunern? Gute Nacht... Nebenbei können ja auch mehrere NetCeiver im Netzwerk sein

Die Idee beim NetCeiver-Protokoll war halt vor allem, DVB wirklich transparent zu übertragen, sodass man auf Client-Seite wirklich so tun kann, als hätte man einen lokalen Tuner.

Hallo,

kann mir einer sagen wo ich die aktuelle Firmware für den netceiver herbekommen ? Aurf der Reel Website finde ich leider nichts dazu.. Gibt es auch eine Anleitung wie ein Firmware Update zu machen ist ?

Gruß
Sebastian

HI,

Razorblade

Zitat

So genug Wunschkonzert, aber ich schätze ich habe mit meinen 3 vdr's (zwei reine Frontends für Live-TV und Replay und ein reiner Recording-Server) auch nicht gerade das üblichste Setup...

Naja, dann sind wir aber zumindest zu zweit

vogls
steht alles im Wiki

MFG
Kris

vogls:

Die FW mit dem alten CAM-Support ist 98D.

http://www.reelbox.org/software/netceiver/netceiver_98D.zip

Eine Beschreibung des Updatevorgangs (jetzt auch mit Verwaltung der FWs) ist im readme.

Nano:

Ursprünglich sollte dvbfuse wirklich nur die Kanalliste nehmen. Den rohen TS mit VPID/APID, der da rauskommt, versteht aber eigentlich nur der mplayer und auch nur bei SDTV. Alle anderen brauchen PAT/PMT. Da hat es sich dann angeboten, den ganzen SI-Kram gleich intern zu machen...

Schön, dass endlich mal einer etwas mit unseren Quellen anfangen kann.
Die Sache mit dem Loopback-Interface unter Windows ist etwas ärgerlich, aber lösbar. Hierzu muss man den nicht defaultmäßig im System vorhandenen Loopback-Adapter von Hand nachinstallieren (eine Anleitung gibt es hier: http://support.microsoft.com/kb/839013).
Wir würden uns freuen, wenn du die Ergebnisse deiner Arbeit ebenfalls veröffentlichen würdest.

Deti

Zitat

Original von Nano
Die Multicast-Geschichte ließe sich aber für den Fall nutzen, wenn man den Netceiver direkt an den Server-PC dranhängt, der dann mit meinem Tool die UDP Multicasts über ein anderes IF für das LAN bereitstellt. Quasi als DVB-IPTV Head. Dann wird das LAN nicht doppelt mit den Multicasts belastet. Oder man arbeitet mit VLAN und entsprechenden Switches, die nur an den gewünschten Endgeräten jeweils die nativen IPv6 Multicasts de Netceivers zur Verfügung stellen.

Genau dieses Scenario würde mich interessieren, ich habe im Moment einen Netceiver an einem isolierten Netz an meinem vdr (server, recording only) mit eth1 und den Rest des LANs (inkl. zwei vdr frontends die wiederum auch ein zweites eth ins Netceiver Netz haben).
Wünschen würde ich mir einen simplen Netceiver to DVB-IPTV Konverter (auf Linux) und dann die vdr's nur noch im regulären LAN zu haben (dann vermutlich mit IPTV Plugin anstatt mcli)

Zum mcli-Plugin aus dem SVN: Ich habe gerade versucht das mit VDR 1.7.9 zum Laufen zu bekommen.

Die VDR-Patches lassen sich erstaunlicherweise auch auf 1.7.9 ohne Problem anwenden. Das Plugin baut ebenfalls. Beim Start bekomme ich aber:

vdr: /usr/lib/vdr/plugins/libvdr-mcli.so.1.7.9: undefined symbol:  _ZN11cMcliDevice12GetTSPacketsEPhi

Woran liegt das und wie wird das gefixt?...

Hast du VDR neu gebaut?

Ja. VDR neu gebaut und auch Plugins neu gebaut. Dennoch läuft das Plugin nicht.

Also: Fix für das Problem mit VDR 1.7.9 ist der erste Patch. Könnte real_schorsch sich da bitte mal äußern, was ich da eigentlich aktiviert habe?

Der zweite Patch sorgt dafür, dass das mcli-Plugin auch außerhalb des VDR-Source-Trees gebaut werden kann.

Etwas komisch finde ich, dass ich es nicht schaffe, direkt einen einzigen Tuner auf einer Doppel-Tuner-Karte des Netceiver anzusprechen. Ein Stück isolierter Draht löst das Problem im Moment (Loop des einen Tuners auf Eingang des zweiten gesteckt).

> was ich da eigentlich aktiviert habe?

GET_TS_PACKETS ist eine Optimierung im vdr-core, die es erlaubt, mehrere TS-Packete auf einmal in das vdr-System zu stopfen. Das reduziert die Last bei höheren Datenraten durchaus. Warum du das Flag im mcli anschalten musst, verstehe ich nicht ganz. Ohne das define wird jedes Paket einzeln kopiert.

> Etwas komisch finde ich, dass ich es nicht schaffe, direkt einen einzigen
> Tuner auf einer Doppel-Tuner-Karte des Netceiver anzusprechen.

Der NetCeiver nutzt die Tuner, so wie es ihm passt (da ist eine Heuristik zur Ressourcenverwaltung dahinter). Nachdem die Tuner über das Netzwerk auch virtualisiert sind, kann man explizit die Tuner nicht auswählen, auch wenn es der ungepatchte vdr/femon einem Glauben machen will. Es wird eben der Tuner genommen, der "am besten" zur Anfrage passt.

Wenn du wirklich nur einen Tuner angeschlossen hast (Loop-Through ist böse, das weiss der NetCeiver nicht und kann damit bei Bandwechseln auf die Nase fallen), solltest du den anderen in der netceiver.conf ausschalten (preference auf -1).