Posts by Nano

    So, bis jetzt rennt alles. Auch mit der Original-Fernbedienung. :D


    Aufnahme und Wiedergabe funzt auch. Allerdings habe ich alte PES-Aufnahmen noch nicht getestet.
    HD ist auch noch nicht getestet.


    Das einzige Problem was ich derzeit habe, ist, dass ich bei der ARD Probleme mit dem AV-Sync habe.


    Quote

    Originally posted by real_schorsch
    > Dann kommt die Fernbedienung dran.


    Aus /dev/reeldrv kommt das Zeug prinzipiell im LIRC-Format raus (32Bit, 1us Einheiten, bit 24 ist mark/space). Da könnte man vermutlich auch direkt einen lircd dranklemmen, habs aber nicht probiert. Der wird dann wohl auch Probleme mit der Reel-FB haben, deren Kodierung ist recht seltsam. Ein passender Dekoder dazu ist aber in reelbox-control/frontpanel_nc.c.


    Kann ich nicht einfach /dev/input/rbfp0 nehmen und dann das Remote-Plugin dazu?

    So. Das mcli-Plugin ist eingebaut.


    Der VDR startet und ich sehe das OSD. Ich sehe auch EPG-Daten der Sendung die gerade läuft, aber kein Bild und kein Ton.


    Stattdessen jede Menge:

    Code
    1. AddPacket: Buffer overflow!! 1048576 188 1048576


    Ich habe das rbmini-Plugin _ohne_ #define ALWAYS_TS übersetzt.


    Kann mir jemand mal kurz erläutern, was momentan Stand der Dinge bei vdr-1.7.10 ist in Sachen der intern verwendeten Transport-Formate (TS/PES)? Reel hat das remux.c ja fast komplett umgeschrieben. Intern wird durch das #define ALWAYS_TS wohl nur noch TS benutzt. Wie ist das derzeit beim VDR-1.7.10?

    Tach!


    Ich wollte mal kurz berichten. :)


    Mein Netclient bootet jetzt sein rootfs von einem NFS-Server.
    Ich arbeite momentan also auf dem Netclient quasi mit einem Debian Lenny für ARMEL.


    Den VDR-1.7.10 habe ich inzwischen kompiliert. Das Plugin "rbmini", das für die Ausgabe des OSDs und der AV-Daten ist, habe ich für 1.7.10 angepasst.
    Es waren nur eine Hand voll Member-Funktionen, die Reel in die eigene OSD Klasse des Reel-VDR eingebaut hatte. Diese habe ich erstmal rausgenommen.


    Das rbmini-Plugin kompiliert also durch. Jetzt werde ich zum Testen erst einmal das MCLI-Plugin und das Streamdev-Plugin als Input-Devices einbauen.


    Bin gespannt!

    Vielleicht interessiert es ja jemanden:


    Hi!


    Ja, ich habe so ein Teil im Einsatz (mit Netceiver).
    Ich besitze auch keine AVG. Eigentlich brauche ich so eine AVG auch nicht.


    Ein eigener VDR lässt sich bestimmt einbauen. Im SVN sind prinzipiell alle Dinge vorhanden, um so etwas zu bewerkstelligen.


    Das Grundsystem des Netclients ist ein Debian Lenny(?) für ARM(armel).
    Die Anbindung der AV-Hardware erfolgt über ein Plugin namens rbmini. Dieses erstellt im VDR ein Ausgabe-Device. Dieses müsste an den aktuellen VDR angepasst werden.


    Was nicht offen ist, sind die Quellen der Kernel-Module zur Kommunikation mit dem Conexant/NXP Prozessor. Aber mich persönlich stört das nicht.


    Entwickeln lässt sich mit dem Teil auch komfortabel, da das ganze System von einem internen USB-Stick läuft. Dieser wird einfach ausgetaucht. Beim Bootvorgang wird mittels pivotroot auf das neue rootfs des Sticks gewechselt.


    Ansonsten kann man auch direkt hinten an die RS232 des Netclients und direkt den UBoot bedienen.


    Momentan beschäftige ich mich damit, erstmal das Original-Reel-Image für das Teil nachbauen zu können. Die DEB-Pakete aus dem SVN bekomme ich in der passenden chroot-Umgebung mit dem Armel-Cross-Compiler auch übersetzt. Leider bekomme ich nirgendwo eine Info, wie das Basis-Image erstellt wird.


    Hallo!


    Es wird evtl. Zeit, dass wir noch so einen Thread für den Netclient aufmachen. :)


    Grob gesagt, läuft da quasi das gleiche wie auf der AVG. Also auch ein modifizierter VDR. Das Grundsystem ist Debian-like. Die Ausgabe der Video/Audio-Daten zum HW-Decoder erfolgt über ein spezielles Plugin, was ein Output-Device für VDR erzeugt. Der HW-Decoder kann laut Datenblatt H.264, VC-1 und MPEG2 verarbeiten.


    Ich habe so ein Teil zuhause und spiele damit schon fleißig herum.
    Da das Teil auch recht offen ist (bis auf die Kernel-Module für die HW-Anbindung) könnte man vermutlich tatsächlich einen eigenen VDR draufpacken. Zumal das ganze rootfs intern von einem USB-Stick läuft.
    Also Reel-VDR Stick rausziehen und den Stick mit dem eigenen System reinstecken. NFS wird - so wie ich das sehe - auch unterstützt.


    Prozessorplattform ist ARMEL.


    NACHTRAG:
    Entwicklungsumgebung hier:
    http://wiki.reel-multimedia.co…ntwicklung#Reel_NetClient

    Hallo,


    ich wollte nur kurz bescheid geben, dass ich das Streaming-Tool netcv2dvbip für den Netceiver nochmals überarbeitet habe.
    Unterstützt wird jetzt auch IGMPv2 und IGMPv1.


    Code
    1. https://svn.baycom.de/repos/vdr-mcli-plugin/mcast/netcv2dvbip/


    Außerdem ist jetzt auch das WIN32-Projekt-File unter "client/win32/visualstudio" zu finden.


    Code
    1. https://svn.baycom.de/repos/vdr-mcli-plugin/mcast/common/win32/visualstudio/netcv2dvbip/


    Viel Spass damit!


    PS:
    Seit letzter Woche habe ich endlich mein Netceiver-Gehäuse. :)
    Seit gestern dann nach 8 Monaten endlich den Netclient. :)
    Leider habe ich es gewagt, die Stromversorgung auszuschalten, während der Netclient im normalen Standby war. Jetzt sehe ich nur noch das Boot-Logo und er startet nicht mehr. ;(
    Jetzt darf ich nach einem Tag schon an den internen USB-Stick, um das Image neu zu flashen. Hoffentllich bringt das was............

    Quote

    Originally posted by Razorblade


    Ich dachte eher an das Streamformat, ich vermute mal Du schickst die MPEG-Header per RAW-UDP auf die Reise (H.610)? Wenn ja sollten das Häppchen à 188bytes sein, diese darf man aber zB laut DVB-IPTV Specs bis 7x188bytes aggregieren um mehr Durchsatz zu erreichen.


    Ich nehme den TS, so wie er vom Netceiver kommt. Dann werden pro UDP-Paket 7 TS-Pakete verschickt. Nur die PAT wird neu generiert und enthält nur den Eintrag für die eine PMT des ausgwählten Programms.
    Das habe ich alles von dvbfuse 1:1 übernommen.


    Reines UDP ist ja laut DVB IPTV Spec.auch konform. Es muss nicht zwingend RTP sein.


    Ich habe es übrigens bis jetzt nur mit VLC getestet. Bin gespannt auf Deine Tests mit dem IPTV-Plugin für VDR.


    Was mich noch interessieren würde, wäre ein Plugin-Interface, so dass man ankommende TS über ein Plugin noch weiter behandeln könnte und danach weitersenden könnte. Man kann sich ja denken wofür...;)


    Ich vermute nur, dass es für mich zu aufwendig ist. Vor allem, weil ja faktisch schon eine Lösung existiert. VDR+streamdev-Plugin(CVS mit IGMP)+böses Plugin


    Ich habe ganz üble Bauchschmerzen, wenn ich mir die Zukunft von DVB in Sachen CI+ usw. anschaue. Vermutlich wird es da ja wohl nie ein CAM geben, was man in den Netceiver stecken kann, oder? Höchstens immer nur in jede einzelne Box.
    Aber die Thematik hatten wir ja schon ein paar Seiten vorher...


    In den letzten Wochen hat man aber recht häufig Meldungen darüber gelesen, dass immer mehr Netzbetreiber und HW-Hersteller auf diesen Zug aufspringen. Mich würde wirklich interessieren, wie zukunftsicher man mit der Reel Lösung in Anbetracht dieser Entwicklungen noch ist...
    Es wäre wirklich schade drum...

    Quote

    Originally posted by Razorblade
    Nano : Gefällt mir echt gut, werde ich die Woche gleich mal testen (mit VLC und IPTV-Plugin als Clients)!
    Hattest Du das mit den DVB-IPTV Specs im Hinterkopf geschrieben oder einfach so?


    Gruß,
    Razor


    Ich hatte mir die DVB-IPTV Specs mal angeschaut. Im Wesentlichen ging es dort aber nur um die ganze Verwaltung drumherum. Ich glaube, das meinte realschorsch auch mit "Moloch". :)


    Vielleicht hat ja nun jemand Lust, das ganze Service Discovery zu machen? :) Stichworte sind hier: DVBSTP, SD&S, XML.


    Hier wird das Metadaten-Server genannt:
    http://www.irt.de/webarchiv/sh…=MzQzMCMxMDA0MjEzMTAjcGRm


    Laut DVB-IPTV gibt es übrigens zwei erlaubte Arten, Metadaten zu transportien, entweder im TS oder in den SD&S XML Strukturen.
    Mit dem Tool wird die erste Lösung realisiert, ist ja eh schon so vorhanden.


    Momentan räume ich noch weiter den Code auf und mache es etwas sicherer in Bezug auf die Bedienung. Wenn alles korrekt sein soll, müsste wohl auch IGMPv1 und IGMPv2 noch mit unterstützt werden.
    Außerdem gibt wohl Settop-Boxen, die nur max. IGMPv2 sprechen. ;(


    Gruß
    Nano

    Hallo!


    Hier die erste Version des OnDemand Multicast Streamers für den Netceiver. Das Projekt-File für Visual C++2008 kommt morgen.


    ---


    HOWTO - netcv2dvbip


    1)

    Code
    1. svn co https://svn.baycom.de/repos/vdr-mcli-plugin/mcast/


    2)

    Code
    1. wget http://www.vdr-portal.de/board/attachment.php?attachmentid=22992
    2. mv attachment.php?attachmentid=22992 netcv2dvbip-0.0.1.tar.bz2


    3)

    Code
    1. cd mcast
    2. tar xfj ../netcv2dvbip-0.0.1.tar.bz2
    3. cd ..


    4)

    Code
    1. cd client
    2. make
    3. cd ..


    5)

    Code
    1. cd netcv2dvbip
    2. make


    6)

    Code
    1. ./netcv2dvbip -b <ip_address of streaming interface> -i <interface with netceiver network>

    Zur Info:


    Das Netceiver-Gehäuse Kit ist nun offensichtlich auch im Online-Shop bestellbar. Zu finden unter "Zubehör" für 109,-EUR.


    Quote

    * Gehäuse-Deckel & Gehäuseboden
    * 60W Tischnetzteil inkl. Power Adapter


    Hab' gerade direkt bestellt. Soll dann auch in 4 Wochen - Mitte Oktober - verfügbar sein so wie das Netceiver-Komplettpaket.


    Hoffentlich wird das mit dem Netclient auch mal langsam was. :)


    Gruß
    Nano

    Hi!


    Wollte nur mal kurz becheid geben, dass das IPTV per IGMP nicht eingeschlafen ist. Bin nur seit dem 02.09. im Urlaub und komme erst am 17.09. wieder nach DE.


    Unterstuetzt wird uebrigens erst mal nur IGMP V3.
    Die aktuelle CVS-Version des Streamdev-Plugins kann uebrigens auch per IGMP V1&V2 streamen. Ich habe mich dort ordentlich am Code bedient.


    Warum nur IGMP V3? Weil dort alle Membership Reports an die eine zentrale Multicast Adresse 224.0.0.22 gehen. Bei V1&V2 muss der Server/Router per setsockopt( JOIN_MULTICAST_GROUP ) in jede Gruppe eintreten, um dort auch die Reports zu empfangen. Koennte man vermutlich zwar auch mit dem Promisc Modus und der libpcap machen, ist aber dann eine Abhaenigkeit mehr. Aktuelle Kernel und mind. Windows XP sprechen eh IGMP V3 per default.


    Es funktioniert momentan schon recht gut und recht fix. Getestet mit VLC unter Windows und dem ncv2iptv Tool unter Linux.


    BTW: Hat mal jemand einen Namensvorschlag fuer das Teil? netcv2iptv? ncv2iptv? dvbiptv?




    Gruss
    Nano

    Quote

    Original von Razorblade


    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)


    Ja genau das wird es auch sein. Das Teil soll unter Windows und Linux laufen. Es wird ein einfaches Konsolen-Tool. Für den Betrieb unter Windows möchte ich aber auf jeden Fall die Möglichkeit haben, dass die generierten Multicasts nicht wieder ins LAN geblasen werden. Dank Detis Hinweis, werde ich diesen MS Loopback Adapter mal installieren, mit dem das hoffentlich klappt. Dann kann man auch dieses DVBLogic DVBLInk IPTV unter Vista bzw. Win7 benutzen.


    Mit dem Tools sind dann folgende Konstellationen möglich:
    1) Netceiver ---ipv6---> eth0#Linux-Server mit Tool###eth1 ---ipv4---> Clients


    2) Netceiver ---ipv6---> eth0#Client mit Tool#lo ---ipv4---> App auf Client

    Tach!


    Kurzer Zwischenbericht von mir:
    Ich wollte ja möglichst einfach unter Windows den Netceiver nutzbar machen.


    Ich habe jetzt ein kleines Tool gebaut, was auf lokale IGMP (IPv4) hört und dann entsprechend einen lokalen TS-über-UDP Stream zur Verfügung stellt oder ggf. wieder stoppt.


    Eine Multicast-Adresse der Form 239.0.0.1 entspricht dabei Kanal 1.
    239.0.0.2 entspricht dabei Kanal 2, usw.


    Also kann man mit udp://239.0.x.y jeden Kanal zwischen 1-65534 erreichen.
    Der Port ist dann immer gleich.


    Getestet mit VLC. Muss jetzt noch alles schön machen. :)


    UPDATE: Zu früh gefreut! :(


    Zwei RIESIGE Nachteile:
    1) Das Multicasten klappt nicht auf dem Loopback-IF.
    2) Aufgrund von 1) muss ein echtes IF genommen, was dann auch alle
    Pakete an das angeschlossene LAN raushaut. :( SHIT!


    Dann muss ich jetzt wohl doch HTTP einbauen. Grmpf.


    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.


    Gruß
    Nano