Posts by real_schorsch

    Ich denke da z.B., dass sich überschneidende PIDs von zwei verschiedenen Programmen angepasst werden müssten, entsprechend auch die Ansteuerung des CAMs nicht stur die PIDs aus der PMT durchreicht und dass beim Demultiplexen die PIDs ja wieder zurück gemappt werden müssen.

    Genau das macht der NetCeiver (komplette Filter/Rewrite/Mux/Demux/Rewrite-Matrix in der HW). Prinzipiell kann er dazu alle 6 TS-Ströme zusammenmischen (wenn es denn CAM+Smartcard gäbe, die damit zurechtkommen würden...). Die paar relevanten SIs werden von der CPU entweder umgeschrieben oder gleich synthetisch erzeugt und wieder in den TS zum CAM eingebaut. Die Feinheiten betreffen dann eher die diversen Bugs/Beschränkungen der CAMs, ob alle Services oder nur Audio+Video, etc... ;)

    Zu den DD-Karten bzw. deren Fähigkeiten kann ich nichts sagen, aber als "Erfinder" von MTD zu den Voraussetzunge sehr wohl.

    a) "Echtes" MTD heisst, dass Dienste von mehr als einem Transponder (typischerweise aber demselben Anbieter) dekodiert werden können. Es soll Geräte geben, die unter MTD nur verstehen, dass man zwei Dienste von einem Transponder dekodieren kann. Letzteres kann der vdr schon lange, wenn es das CAM auch kann.

    b) Nicht viele CAMs können überhaupt mehr als einen Dienst dekodieren. Im wesentlichen ist es das Alphacrypt.

    c) Für echtes MTD ist Vorrausetzung, dass das CAM mehr als einen Dienst dekodieren kann. Aber: Es weiss nichts und muss auch nichts davon wissen, dass das von mehr als einem Transponder kommt. Das ist deswegen unnötig, weil die CI-Slot-Hardware die Transportstreams filtert, multiplexed, und evtl. die PIDs und tw. auch die Service-Infos umschreiben muss. D.h. das CAM sieht einen ganz normalen Transportdatenstrom, so wie er sonst von einem Transponder kommt. Filtern ist nötig, weil zwei Transponder zusammen einerseits mit vielen PIDs kollidieren und andererseits die Gesamtrate meistens schon grösser als die für einen CI-Slot zugelassene ist (max. 9MB/s).

    d) Der vdr kann mit Bordmitteln kein MTD, weil er direkt mit dem CAM redet und keine Schnittstelle fürs PID/SI-Rewriting hat.

    Wer hat hier eigentlich was von VAAPI gesagt?

    Achja, der PowerVR macht auch nicht die Videodekodierung, der ist "nur" für den 3D-Kram (GL) zuständig. Allerdings kann der PowerVR dekodiertes Video auch als Textur auf irgendwelche 3D-Objekte legen (Wusch-flupp ;) ), gibt genügend Demos mit Source dazu. Machen wir aber (noch...) nicht.

    BTW2: RMM ist gerade auf der HighEnd in München. Da sollte man schon ein paar Previews bekommen können.

    > Welche DVB-S/S2 Karte kann überhaupt durchschleifen, ist das überhaupt
    technisch sinnvoll
    > umsetzbar aufgrund der Schaltspannungen?

    Ok, ich versuchs nochmal, anscheinend war mein Gedankensprung zu gross: Man KÖNNTE bei SCR mit mehreren Tunern in einem PC auf alle bis auf eine Dose verzichten, wenn a) die Karten HF-mässig durchschleifen können und man b) den ganzen SCR-Kram auschliesslich über die erste Karte abwickelt. Woher die Kommandos für die Downlinkselektion kommen, ist ja egal. Bei einigen Dualtunern könnte das abhängig vom HF-Frontend auch schon intern gehen. Mit dem STV6120 geht es zB., der hat eine interne Schaltmatrix. Weiss nur grad nicht, ob es schon Karten mit dem gibt....

    > Ok, warum widersprichst Du Dir dann selbst?

    Ich seh keinen Widerspruch. Ich sagte nur, dass trotz dieser HW-technischen Möglichkeit, die Dosen einzusparen (spart Geld und Kabelverhau), der vdr das nicht unterstützt.

    > Naja, SCR/EN50494 ist ein Ab-Art von DiSEqC 1.0, was es eben so umgänglich macht

    Danke, habs für den NetCeiver auch programmiert ;)

    > Von daher würde Deine DiSEqC Einschränkung auch hier gelten ...

    Äh... man kann im vdr für das Tunen von Karte#2 die Diseqc-Messages über Karte#1 schicken, die durchgeschleift an #2 geht?

    > Wie schließe ich dann mehrere Karten an das eine Kabel an?

    Mit mehreren Unicable-Auskoppeldosen.

    > Die meisten haben ja keinen Ausgang zum Durchschleifen

    Der würde so auch nichts helfen, weil da nicht nur keine Spannung sondern auch kein Diseqc durchgeschleift wird. Daher müsste dann der gesamte Diseqc-Verkehr über den "ersten" Tuner abgewickelt werden, was AFAIR der Unicable-Support im vdr nicht kann.

    > Das Einbrenn-Problem seh ich nicht so. Die angegeben Lebensdauer ist 5
    > bis 10 mal höher als bei alten Röhrenfernsehern, und die haben bei mir
    > ewig gehalten.

    Die Röhrenglotzen hatten aber auch kein Problem, mal zwei Stunden dasselbe Programm auch in "hell" anzuzeigen. Das ist *heute* ein Problem mit den Plasmas, die Lebensdauer an sich ist da egal. Stöber mal durch die Foren, da gibt einige, die das für "erledigt" gehalten haben und jetzt zB. ein ARD-HD-Einser-Logo links oben haben. Aber in jedem Programm... Geht auch nicht mehr weg, selbst mit den "Waschprogrammen" aus dem Servicemenu. Was ich eh witzig finde, ist das jetzt eine Mimose, ein Tintenstrahldrucker oder doch nur ein Fernseher? :wow

    > ausser Plasma-Technik

    Und genau das ist der dickste Haken überhaupt. Einbrennen tun die immer noch (egal was das Marketing sagt), man muss sie wie Autos einfahren, mehr als eine Stunde dasselbe Senderlogo bei hohem Kontrast vermeiden, etc. Noch dazu sieht das Bild IMO einfach Sch... aus. Es flackert sichtbar (ja, auch bei x*100Hz) und hat eine miese Farbauflösung bei dunklen Stellen (wg. temporalem Dithering) .

    Man müsste halt noch rausfinden, wie man bei den Tunerkarten die Datenstromverschaltung macht. Ich kenne die Karten halt nicht, daher kann ich dazu wenig sagen. Mit dem vdr-1.4 hat das jedenfalls bei der Lite geklappt, ich zweifele aber, dass die Portierung mit 1-2 Zeilen gemacht ist. Als "Inspiration" sollte es aber auf jeden Fall taugen.

    > Gibt es zu der "reeldvb.h" auch einen direkten download Link?

    svn://reelbox.org/testing/src/kernel/reeldvb/

    Das ist aber "nur" der Kerneltreiber für das Lite-DVB-FPGA, vom .h werden da AFAIR nur die ioctl-Namen gebraucht.

    Geht zwar etwas OT, aber was solls: Das mit den "kommerziellen" Entwicklern klingt zwar nett und ist IMO in komplexen Nischenbereichen auch das einzige Mittel, um was voranzubringen. Meine Erfahrung bei RMM zeigt aber, dass das kaum einer honoriert, selbst wenn fast alles (soweit legal möglich) Open Source ist. Stattdessen wird dann rumdiskutiert, wie der böse Kommerz die Arbeit der Freizeitentwickler trotz GPL ausschlachtet, warum die HW überhaupt was kostet (ja, was erlauben die sich eigentlich, die paar 100KEUR für die Entwicklung wieder reinholen zu wollen...) oder warum einzelne hart NDA-isierte Treiber (zB. für HDMI) nur als Binary rausgegeben werden und das das KO des ganzen Dings ist. Die Welt ist halt undankbar ;)

    On-Topic: Das reelcam-Modul für die Lite ist hier: svn://reelbox.org/testing/src/vdr-plugins/src/reelcam-0

    Der Trick ist, alle CAMs für den vdr auf einen DVB-Adapter zu mappen und die TS-Verschaltung "on-demand" beim Channelswitch zu machen. Alles Lite-spezifische ist recht einfach an den ioctls im Code auszumachen, die steuern die CAMs und die Verschaltung. Der Rest sollte generisch nutzbar sein, allerdings werden wohl ein paar Anpassungen auf vdr-1.7 notwendig sein.

    Ist ja schön, aber der höhere Timeout dort löst das ursächliche Problem nicht. Und das ist, dass es so oder so evtl. länger als bei lokal angebundenen Tunern dauern kann, bin ein Lock da ist und Daten kommen. Ob die Tuner an oder aus sind, ändert nichts an deren Verfügbarkeit für den vdr selbst, also kann es nur was mit dem Zustand zu tun haben,,, Aber was jetzt da so "intelligent" ist, sehe ich im Code grad nicht...

    > Das glaub ich so nicht, denn via Streamdev hatte ich immer ein Bild. Ich
    > weiss natürlich nicht, ob der streamdev da irgendwas in der Richtung
    > macht.

    Die Auswahl der Tuner macht jede Datensenke selbst, von daher kann es da schon grosse Unterschiede geben.

    > Rein Hypotethisch, was passiert wenn ich ein Tunertimeout von sagen wir 2
    > min habe und der VDR bleibt 10 min auf ein und denselben kanal, gibt
    > das mcli-plugin an den Netceiver eine Meldung ala "hier guckt noch
    > jemand"? Was ist, wenn aus irgendeinem Grund eben diese Meldung
    > wegbleibt und der tuner einfach ausgeht...

    Das mcli-PI hat einen Timeout von 10 SEKUNDEN (!!!) für alle PID-Receiver, die keinen ganzen Service ziehen. Der vdr (und die diversen Plugins) gibt nämlich freiwillig (d.h. ohne Tunerknappheit) keine PIDs mehr her, wenn er mal den Tuner angefasst hat. Damit würden alle Tuner bis zum Abschalten belegt werden, und das nur für SI, EPG und so Kleinkram. Das würde die ganze Ressourcenverwaltung ruinieren.

    Alle PIDs, die einem Service zugeordnet sind (also "Programme" fürs Schauen, Aufnehmen und Streamen) sorgen für einen regelmässigen Refresh aller abonierten Multicastgruppen übers Netz (d.h. alle ~10s geht per MLDv2 eine Liste aller gewünschten Transponder + deren PIDs raus). Damit haben die Multicastgruppen (MCG) für einen Transponder einen Usage Count !=0 im NetCeiver, daher läuft das Streaming der PIDs weiter. Im NetCeiver werden die MCG entweder aktiv über MLDv2 gelöscht (via DelPid() zB. beim Zappen) oder die Updates werden nicht mehr empfangen (Empfänger "verendet", spontan vom Netz gefallen, ...). Ohne Update gibts einen weiteren Timeout (auch 10s), der für jedes Empfänger<->MCG-Paar den MCG-Usage Count runterzählt. Ist er 0, will gar keiner mehr diese PID von dem Transponder haben und das Streaming dafür wird eingestellt (der NetCeiver streamt ja nur selektiv PIDs). Ist der Usage-Count für den Transponder insgesamt 0, fängt der Tuner Timeout an zu zählen.

    Ist alles sehr schön zu sehen: Nimm netcvlogview (die NetCeiver-Logs werden auch per Multicast gesendet) und schau, was so passiert, wenn man den ganzen vdr "im Lauf" zB. per SIGSTOP oder Debugger anhält. Das triggert mangels MLD-Update die MCG-Timeouts, der Usage Count für den/die benutzten Tuner fällt sehr schnell auf 0. Wenn dann noch der Tuner Timeout kurz ist, wird kurze Zeit später BER auf "deaddead" gesetzt. Dann erst ist der Tuner (inkl. LNB-Versorgung) aus.

    > hattest du mal zeit gehabt zu schauen?

    Ja, Den DVB-register-Calls vom Kernel ist wieder mal ein neuer Parameter gewachsen. Leider hat C keine Default-Werte wie C++, damit würde das gar nicht auffallen. Compilieren tuts schon wieder, aber testen muss ich es noch.

    > Die Frage ist halt, ob es wirklich nur ein Problem ves VDR ist, oder ob es nicht an der DVBAPI von Linux ist?

    Liegt es an der Henne oder am Ei... Beide haben die FF als ihre HW-Basis. Und bis vor kurzem gab es ja auch kaum was anderes, was sich nicht in das Konzept reinquetschen lies. Es hat auch wohl keinen interessiert, dass es mal was anderes geben könnte. Hab ja schon zu Lite-Zeiten das Thema mal angesprochen (k.A. ob vdr-ML oder dvb-ML). Im Endergebnis ist RMM eh immer selbst schuld, dass sie was anders machen wollen ;)

    > Die DVB Applikationen unter Windows haben ja dieses Problem nicht.

    Das DVB-System von Windows ist sehr rudimentär bzw. "unspezifisch". Man (=die Anwendung) baut da hauptsächlich Direkt-X-Graphen zusammen, so ziemlich alles wird in den SW-Filtern erledigt. Intelligente HW wie die FF-Karte (die PID-Filter hat, und auch nicht den ganzen TS rüberbekommt) ist da gar nicht vorgesehen. Die Devicetreiber liefern alles, der Filtergraph der Anwendung sucht sich das Interessante raus. (OT: Das ist ja u.a. auch der Grund, warum ein BDA-Treiber für den NetCeiver sehr schwer ist: Man bekommt gar nicht mit, was die Anwendung "guckt").

    Der Vorteil ist natürlich, dass die Treiber selbst fast nichts können müssen und die Userspace-SW die "Features" definiert.