Posts by Razorblade

    könntest Du dann evtl die fertig kompilierten vdr-fbfe binaries und am besten den source-diff vom xine-lib mit Deinen änderungen auch noch publizieren?


    Ich habe versucht mein xine wirklich aufs nötigste abzustrippen (siehe 3 zeilen-langes configure statement), vielleicht kamen viele der nötigen änderungen auch daher das Dein xine noch auf releativ viele andere sachen linkt.


    mit pthread im makefile habe ich inzwischen probiert, bin aber an der gleichen stelle hängengeblieben...

    Hallo,


    da es mit dem vdr-support im nativen PCH eher rückwärts anstatt voran geht, wollte ich mal probieren den vdr-fbfe mittels xinelibout an den poppi anzubinden.


    Hab mir die cross-compile chain von Lundman gezogen und auch schon directfb und zlib kompiliert, allerdings scheitere ich gerade an xine-lib, hat jemand eine Idee:



    das ganze mit dem vanilla xine-lib-1.1.15
    Die 1.1 und 1.2 mercurial snapshots scheitern noch früher


    Mein configure habe ich gestartet mit:

    Code
    1. ./configure --target=mipsel-linux-uclibc --host=mipsel-linux-uclibc --build=x86_64-linux-gnu --prefix=/usr/local/mips --disable-iconvtest --with-zlib-prefix=/usr/local/mips --disable-vcd --enable-directfb --without-imagemagick --without-alsa --without-esound --without-jack --without-speex --without-theora --without-vorbis --without-pulseaudio --without-sdl --without-caca --without-xcb --disable-asf --disable-nosefart --disable-faad --disable-dts --disable-dvdnavtest --disable-samba --disable-gdkpixbuf --disable-gnomevfs --disable-artstest --disable-opengl --disable-xvmc --disable-dxr3 --disable-xshm --disable-syncfb --disable-ffmpeg-uncommon-codecs --disable-xinerama --without-x --disable-fb --enable-a52dec --disable-dvdnav


    und folgendes meldet xine nach dem configure durchlauf:

    Davon abgesehen ist XFS gerade bei wenigen großen Dateien (vdr's à 1GB würde ich in diesem Zusammenhang mal als groß bezeichnen) performanter als ext3 und unterstützt (gerade im Zusammenhang mit RAID und LVM wichtig!) ohne zusätzliche Modifikationen Online-Resizing.


    Was die Wahl des RAID-Levels angeht, so würde ich keine pauschale Empfehlung abgeben wollen ohne Deine Nutzungszwecke genau zu kennen, aber ich fahre seit einiger Zeit mit Raid6 ganz gut:
    Wie ja jeder weiß ist es nicht eine Frage "ob" sondern "wann" eine HD über den Jordan geht. Für die Zeit der Wiederbeschaffung (bzw Garantieaustausch) will ich dann aber nicht mit verminderter Redundanz leben (RAID5) oder erst durch einen Rebuild Zeit/Leistung verlieren (RAID5 + HotSpare).
    Die Anwendung für RAID10 würde ich wegen des immensen Verschnitts nur sehen, wenn es wirklich um die reine I/O-Leistung geht...

    ... nur wenn man eine FF im System hat, da vdradmin afaik nur das /dev/video abgreift, dass es ja bei Budget's nicht gibt.


    Ich wäre auch sehr daran interessiert, betreibe schon seit Jahren einen "headless" VDR zum Aufnehmen und Streamen aber etwas einfacheres als per ssh die channels.conf oder setup.conf zu bearbeiten habe ich noch nicht gefunden. Das macht aber auch nicht so richtig Spaß, da man dazu den vdr erst beenden muß und z.B. bei neuen Plugins (streamdev, xinelib, usw) nicht ganz klar ist, was in die setup.conf muß, damit es klappt... die Anweisungen in den readme's und how-to's beziehen sich nur aufs OSD.

    Ich verstehe jetzt zwar nicht, was digital mit nicht quadratischen Pixeln zu tun hat, aber ich versuchs mal zu erklären:
    Innerhalb des MPEG Datenstroms hast Du im konkreten Fall 720 Bildinformationen pro Zeile und ein "Pixelverhältnis" von 1:1,06.
    Dadurch werden dann aus den 720 (nicht quadratischen) Bildinformationen letztendlich 768 Pixel bei der Ausgabe.


    Spiel doch mal eine aufgenommene Datei mit mplayer ab, da sieht man schön die Informationen.

    Paravirtualisiert grundsätzlich ja, das geht mit jeglicher i686 Hardware (ohne VT und VT-d), das Interessante ist wohl das PCI-passthrough.
    Wenn es Dir um VT-d (und damit u.U. auch HVM) geht, dann reicht ein G45 definitiv nicht.
    Interessant ist übrigens (teilweise von mir überarbeitete) Seite im XenWiki dazu.


    Für das Passthrough einer PCI DVB-Karte an ein paravirtualisiertes Linux braucht man aber derzeit kein VT-d.
    Wenn man in die XenRoadmap schaut oder sich das ganze mal technisch näher anschaut würde ich aber bei einem Hardwarekauf nichtmehr auf Vt-d verzichten, weil es Dir einfach mehr Flexibilität gibt.
    Du kannst dann nämlich auch(und wenn es nur zum Testen ist) unmodifizierte Betriebssysteme einfach (mit Zugriff auf die DVB-Karte) laufen lassen. Das könnte bei Treiber-Tests/Debugging sehr sinnvoll sein...

    Der PCI-BUS hängt an einer PCIe-Bridge, also ja es geht.


    Das Prinzip ist ja nicht erst im Q45 erstmalig implementiert, neu sind die *verschiedenen* DMA Register und erstmal die Möglichkeit auch den PCIe x16 Slot damit zu mappen.

    Quote

    Original von Thovan
    Ich hab' bisher noch keine Erfahrung mit XEN, stelle mir das auch nicht so easy vor, mal eben fix eine virtuelle Umgebung "on the fly" einzurichten.
    Bisher habe ich mit VMWare und Parallels sehr positive Erfahrungen gemacht und gedachte auch VMWare dann einzusetzen.


    Es gibt bestimmte Sachen, die gehen mit Xen, aber nicht mit VMWare und Parallels, zum Beispiel eben PCI-Passthrough (deswegen auch Vt-d!).
    Das ist nicht nur für DVB-Karten interessant, sondern insbesondere für High-Performance Anwendungen oder eben zum Testen. Man kann nämlich sowohl ganze RAID-Controller (und damit eine I/O Performance erreichen, die mit virtualisierten Geräten nie möglich wäre) als auch Netzwerkkarten durchreichen, was insbesondere für Netzwerkanalyse (tcpdumps, Sniffer im promiscous mode) deutlich interessanter ist als virtuelle Netzwerkkarten, bei denen man nicht sicher sein kann, ob wirklich alles so ankommt wie es "on-the-wire" ist (ungültige Framens, Reassemblierung, etc)
    Der neue Microsoft Hypervisor basiert übrigens auch auf Xen (Microsoft hat den Code von Citrix lizensiert!).




    Quote

    Original von halbfertiger
    Danke für den Tipp. Ich hatte schonmal das MSI G31M2-FD mit ins Auge gefasst, der Q6700 läuft darauf ja. Wegen des vorhandenen Gehäuses ist µATX, und wegen des 24" LCD ist DVI Pflicht. Die drei PCI erschienen mir auch praktisch.
    Aber wie sieht es da mit VT unterstützung aus?


    Bitte nicht VT und VT-d verwechseln!
    - VT ist ein CPU Feature was überhaupt erst volle Virtualisierung (in Xen HVM genannt, in VMWare derzeit in beta) ermöglicht. VT ist auf Intel-Plattformen am "VMX" cpu feature erkennbar (muß in seltenen Fällen auch im BIOS aktiviert werden).
    - VT-d ist ein Chipsatzfeature, um mit Hilfe einer IOMMU Hardware [z.B. PCI, PCIe Karten] zu einem gewissen Grad "gesichert" direkt an eine virtuelle Maschine durchzureichen. Das kann derzeit nur Xen und ist auch noch relativ experimentell, aber in diese Richtung wird es definitiv gehen.


    Zum Board, Vom Namen her vermute ich mal, daß da ein G31 drinsteckt, der kann definitiv kein VT-d.
    Ein preiswertes µATX Board (allerdings nur VGA, kein DVI) wäre zB das Asus P5E-VM DO, habe ich selbst mit einem Q9450.


    Inzwischen gibt es sogar schon den Q45, auch mit DVI onboard, zB:
    Intel Executive Series DQ45CB
    Das wäre das Board meiner Wahl, wenn ich neue (Test-)Hardware beschaffen würde ;-)



    Gruß,
    Razor

    Achte bei den Boards darauf, dass sie VT-d unterstützen! Bei der QuadCore Variante ist das mit einem einfachen und preiswerten Q35 Chipsatz erledigt, bei den Xeon's wirds richtig teuer: Die 3x00er Chipsätze können das nämlich nicht, nur die 5x00er und auch da ist es abhängig vom BIOS, also vorsicht!



    Gruß,
    Razor


    Edit: warum eigtl "außer Xen"? ;-)