Posts by Nano

    Quote

    Original von real_schorsch
    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.


    Danke für den Hinweis. Ich habe den Code jetzt mal studiert. Ich denke, ich werde dann direkt darauf weiter aufbauen.


    Aber noch mal die Frage zum besseren Verständnis:
    Ich bekomme in handle_ts_data wirklich nur die PIDs, die ich auch abonniert habe, richtig? Das heißt also, dass ich die PID des PMT auch abonnieren muss, wenn ich diesen haben möchte, oder?


    UPDATE: Okay, Frage hat sich nach weiterem Nachvollziehen erledigt.
    dvbfuse benutzt also die ganzen PID Einträge der Channels.conf überhaupt nicht, sondern nur die Frontend-Daten (Frequenz, etc.) und die SID. Anhand dieser wird dann in der PAT nach der entsprechenden PMT PID passend zur SID gesucht und die PMT PID dann abonniert. Der Rest ist klar.

    Hallo!


    Bin gerade dabei den TS für die Übertragung per UDP zusammen zu bauen.
    Zu einem TS gehört ja in der Regel mindestens ein PAT und ein PMT.
    Wann und wie oft müssen die eigentlich mitgesendet werden?


    Ich werde mir parallel auch nochmal die dvbfuse Quellen anschauen.
    Aber es wäre prima, wenn dort jemand nochmal etwas zu sagen könnte.
    Ich habe in der DVB-IPTV Spec nur gesehen, dass halt "TS optional SI" erlaubt sind, also mindestens mit PAT und PMT. Aber nichts darüber, wann und wie oft die gesendet werden sollen. Gut, zu Anfang dürfte klar sein.



    Hintergrund: derVLC frißt meine TS ohne PAT/PMT irgendwie nicht. Ich dachte, dass der auch ohne zurecht käme.


    Danke und Gruß
    Nano

    Ich zimmere da mal etwas zusammen unter Windows. Kennt jemand eine brauchbare RTP Lib?


    UPDATE:


    Die meisten Libs scheinen eher den Fokus auf VoIP zu haben.


    Okay, sehe gerade, dass sich hinter RTP gar nicht soviel verbirgt. Ich denke, alles was ich brauche finde ich bei dem Tool dvbstream von den dvbtools.


    http://dvbtools.cvs.sourceforg…iewvc/dvbtools/dvbstream/


    Dort ist alles Wesentliche zu finden, was ich zum Senden von RTP Paketen benötige.

    cinfo : danke!


    Ich habe es gestern unter Linux mit dvbfuse zum Laufen gebracht.
    Gefällt mir schon ganz gut.


    Was leider nicht funktionierte:
    1) Exportieren des dvbfuse-Verz. per Samba.
    2) Einbinden in Mediatomb
    Müsste das funktionieren oder spricht etwas total dagegen?


    real_schorsch : vielleicht sollte einer der PCH bzw. WDTV Besitzer mal in einem entsprechenden Forum kund tun, dass es diese Möglichkeit von dvbfuse überhaupt gibt. Bis gestern wußte ich davon auch nichts.
    Also anfixen quasi...;)


    Razorblade :
    Hab' mir gerade mal diesen Windows-Wrapper angeschaut.
    Sollte es nicht recht schnell gehen, ein kleines Relay unter Windows zu bauen, was mittels der libmcli.so den TS empfängt und dann direkt auf localhost als RTP Mutlicast wiedergibt, so dass der Wrapper dann darauf zugreifen kann? Das könnte man dann auch prima für den VLC benutzen.
    Zumindestens für den VLC bräuchte man sogar erstmal nur TS-over-UDP.
    DVB-IPTV wäre vermutlich die Krönung.


    War das jetzt der Weg für Linux oder Windows? Oder für MacOS? :wow


    Ist halt ein Umweg. Was ist, wenn ich sonst keine Linux-Kiste laufen habe? Auch keine VM oder so.


    Dein Weg interessiert mich aber trotzdem. :)
    Kannste da mal kurz beschreiben, was Du alles für brauchst?

    real_schorsch :
    Na, das hört sich doch gut an.
    Bin am Wochenende über diesen Dokan-Treiber gestoßen, nachdem ich bei Heise über dieses XtreemFS gestolpert bin und dieses ebenfalls den Dokan-Treiber benutzt.


    Schaue ich mir auf jeden Fall mal an. Irgendwas außerhalb des Kernel-Space wäre mir persönlich auch lieber. HTTP wäre auch okay.


    kris : Wo genau hast Du das denn im SVN gefunden?

    Hallo!


    Da der Source vom mcli ja nun frei verfügbar ist und somit auch die Steuerung des Netceivers bekannt sein dürfte, frage ich mich, ob sich schon jemand Gedanken dazu gemacht, wie man an die Multicast-Streams unter Windows empfangen könnte.


    Ich weiß, dass RMM vor (hat/hatte?), etwas für Windows zu bauen, um den Netceiver vermutlich generisch als DVB-Karte aussehen zu lassen (BDA Treiber?).


    Persönlich fände ich es aber schon nicht schlecht, wenn man ein kleines Steuertool für die Senderauswahl unter Windows hätte, das die Fütterung eines VLC ermöglichen würde. Vermutlich müsste neben der Steuerung noch eine Art Relay integriert werden, was IPv6 Multicasts empfängt und dann lokal als einen RTP Multicast für den VLC ausgibt.


    Meinungen?


    Gruß
    Nano

    Hört sich ja interessant an.


    Aber generell würde das dann ja auch heißen, dass ich für jeden Client ein CAM+Karte benötige, oder?


    Wie wird sowas heute denn eigentlich von den PayTV-Anbietern gehandhabt? Muss ich für jedes TV zuhause ein eigenes Abo abschliessen oder gibt es eine zweite und dritte Karte für einen Einmalbetrag dazu?


    Hi,


    ich glaube dieses Thema wurde schon einmal angefragt. Soweit ich mich erinnere war die Aussage, dass es auf absehbare Zeit soetwas nicht geben wird.


    Gerade beim Netceiver stelle ich mir eine Realisierung auch recht schwierig vor, weil CI+ doch vorsieht, dass ein unverschlüsseltes Abgreifen nach dem Interface doch nicht mehr möglich sein soll. D.h. dass die TS-Daten wohl vermutlich bis zum MPEG-Decoder wieder (anders) verschlüsselt werden müssten. Gut, man könnte die verschlüsselten Daten ja über das Netzwerk schicken, aber ob dafür die Netceiver-Hardware ausreicht? Und dann das ganze auch noch auf den Clients jeweils entschlüsseln.


    Kennt da jemand den CI+ Entwurf genauer? Muss das alles in Hardware passieren oder gehen Teile davon auch in Software?

    Aus dem Reelblog vom 12.06.2009:



    Jetzt muss ich ne Runde heulen gehen. ;(
    Hoffentlich bezieht sich das _nur_ auf das Stand-Alone-Gerät und nicht das blanke Gehäuse.

    Quote

    Original von real_schorsch
    "Ein Bauteil" ist gut. *Das* entscheidende Bauteil... Trifft neben RMM auch noch andere, aber das hilft auch nicht weiter... War diesmal mit der SW echt alles recht gut im Plan, aber das Murphy-Abo von RMM mal wieder. Habs schon fast vermisst :(


    Mein Beileid. Hört sich nach Prozessor an...


    Quote

    Original von real_schorsch
    Sieht also fast so aus, als würde der NetCeiver im Blech noch deutlich vorher fertig... Dessen Preis ohne Tuner soll bei 250EUR liegen, den Twin-S2 weiss ich jetzt gerade nicht, auch nicht, ob es da Bundles gibt.


    Wird es denn das Gehäuse inkl. Netzteil und Wandler-Platine auch einzeln geben? Einen Netceiver habe ich ja schon...

    Quote

    Original von Oswald-Kolle
    Gibt es denn mittlerweile eigentlich einen "offiziellen Termin" für Netclient und Netceiver? Anfang Juni haben wir ja mittlerweile... :-)


    Oh nein! Gerade kam die Mail von RMM, dass sich die Auslieferung des Netclients wohl auf Ende August 2009 verschiebt, weil ein Bauteil nicht ausreichend verfügbar sei. Sie versuchen aber wohl, dieses Bauteil schon vorher in kleinen Mengen zu ergattern.


    Und das kurz nach meinem Geburtstag ... ;(

    Quote

    Original von Oswald-Kolle
    Lese ich da richtig - in den Netceiver kann man dann eine Festplatte einbauen und das Ding z.B. zum Aufnehmen nutzen? Also quasi als VDR-Server??


    Ich hatte das bisher so verstanden, dass ausschließlich die DVB-Streams (max. 6xS2) übers Netz verfügbar gemacht werden...?


    Der Netceiver stellt nur DVB-Streams im Netz zur Verfügung, ja.
    Der Netclient ist quasi eine komplette Settop-Box mit Festplatte.


    Netclient != Netceiver