Posts by hennichodernich

    Quote

    Steht denn wirklich nichts im log bezüglich der fehlenden Videoausgabe?


    "SetPlayMode: 0" steht da, anstatt "SetPlayMode: 1" wie früher, als es noch (wenn auch ruckelnd) funktionierte. device.h sagt dazu:

    Code
    enum ePlayMode { pmNone,           // audio/video from decoder
                     pmAudioVideo,     // audio/video from player


    cSoftHdDevice::SetPlayMode(ePlayMode play_mode) in softhddevice.cpp tut demzufolge also nichts. Ich frage mich nur, warum ich dann immer noch den Ton höre.

    Gruß
    Henning

    P.S.: Ich habe gerade gesehen, dass SetPlayMode(int play_mode) in softhddev.c hartcodierte Modes verwendet anstatt des enum ePlayMode... Das sollte mal lieber jemand fixen.

    Quote

    Was spricht dagegen xmbc oder mplayer mal zum testen unter debian heranzuziehen?


    Meine Tests waren unter Debian Wheezy, auf dem mittels nodm als User vdr gestarteten openbox-Desktop. Ich hab' gestern den Deinterlacer getestet: Geht. "mplayer -vc ffmpeg12vdpau -vo vdpau:deint=3 http://produktivvdr:3000/1" kann problemlos das Fernsehbild von meinem Produktiv-VDR darstellen, ruckelfrei, wunderbar deinterlaced, sowohl im Fenster, als auch Vollbild. Das Bild vom VDR bleibt nur leider immer noch schwarz, obwohl ich alles deinstalliert habe, was ich zwischenzeitlich installiert hatte.

    Ich werde demnächst mal yaVDR 0.5 ausprobieren, in einer virtuellen Maschine machte das einen qualitativ hochwertigen Eindruck. Könnte ich meinen Produktiv-VDR zwar nicht direkt drauf updaten, aber eine Neuinstallation könnte ich verschmerzen.

    Gruß
    Henning

    Es wäre gut mal was fertiges zu testen um zu sehen ob die Hardware läuft. XBMC wäre z.B. mal ein unabhängiges Mittel um die VDPAU Fähigkeiten zu überprüfen.


    Ich schrieb doch bereits, dass mplayer auf openSUSE 12.1 und auch der mplayer auf Debian Wheezy problemlos über VDPAU ausgeben können. Was ist nicht getestet habe, ist das Deinterlacing bspw. mittels "-vo vdpau:deint=2" zu testen.


    Das "gefrickel" war halt auf die Fehler bezogen die du beschreibst mit "dem und dem ffmpeg evtl. mit oder ohne vdpau" bzw. dem nicht starten wollenden xserver mittels softhddev usw.

    Ich kenne mich mit den deb Paketen nicht so aus aber ich habe manchmal den Eindruck man kann da dinge kombinieren die nicht zusammenpassen bzw. gehören.


    Man darf halt nur nicht irgendwelche dahergelaufenen Pakete installieren, sondern sollte ganze Repositories hinzufügen und die Pakete per apt installieren.

    Bzgl. des VDPAU-beschleunigten ffmpeg hatte ich erwartet, dass die Unterstützung drin ist, so kenne ich Christian Marillat nämlich. Auf die Frage hier hatte ich dann aber doch mal die configure-Optionen angeschaut und kein --enable-vdpau darin gefunden. "ffmpeg -decoders" listet die VDPAU-beschleunigten Decoder aber.

    Bzgl. des nicht startenden X-Servers: Ich habe keine Ahnung, ob das überhaupt mal jemand unter Debian ausprobiert hat. Eine Suche in den Foren hier war unergiebig.

    Akut ist z.Zt. aber immer noch das Problem, dass ich gar kein Videobild (nur OSD und Ton) habe.

    Gruß
    Henning

    Ich habe irgendwie dien Eindruck in deiner Softwareinstallation liegt einiges im argen. Dieses deb hantieren mit irgendwelchen Packeten und vielleicht noch selbstkompiliertem dazwischen scheint mir mächtig instabil.


    Pardon? Meine letzten Tests liefen ausschließlich auf einem frisch installierten Debian Wheezy. Linux benutze ich seit 1998, Debian seit 2001, c't-VDR seit 2003. Ich bilde mir schon ein, zu wissen, was ich tue. :) Außerdem ist yavdr doch auch nur ein Ubuntu+Extrarepo, ich wüsste nicht, wo denn da der Unterschied zu Wheezy+e-tobi sein soll. Das einzige Problem ist m.E., dass viele "Frickellösungen" für eine bestimmte VDR-Distri hingefrickelt werden und dann auf einer anderen Systemgrundlage nicht mehr funktionieren. yavdr wäre wohl noch ok, da Ubuntu auch das Debian-Paketmanagement verwendet und ich mich nicht sonderlich umgewöhnen müsste.

    Gruß
    Henning

    startet denn der xserver? Du darfst nur die Option -x verwenden und nicht -d für detached. Ist im Wiki gut beschrieben.


    War nur ein einzelnes "-x" in der plugins.softhddevice.conf, sonst nix. Damit steht X dann als defunct in der Prozessliste, nicht einmal ein Log wird nach /etc/X11/Xorg.0.log geschrieben.

    Ist aber auch egal, nodm als User vdr funktioniert ja. Das Problem liegt jetzt woanders (s.o., OSD und Ton da, Videobild nicht).

    Gruß
    Henning

    hast Du 1 oder 2 Memory Module ? Ich hab schon länger keinen ION mehr, aber da war das doch so, daß man besser 2 Module installiert da die beiden ja interleaving machen und man damit erst die Bandbreite hinbekommt.


    Ist nur ein 2GB-Modul, Du könntest damit aber Recht haben. Dagegen spricht, dass diese Hardware unter openSUSE 12.1 H.264-Videos in SD-Auflösung ruckelfrei abspielen kann, wenn auch ohne Postprocessing.

    Ich habe jetzt übrigens ein ganz anderes Problem: VDR (mit streamdev-client) zeigt kein Fernsehbild mehr, OSD ist da und reagiert, und den Meldungen im /var/log/user.log zufolge decodiert VDPAU auch irgend etwas. Das einzige, was ich geändert hatte, war die Build-Dependencies von ffmpeg zu installieren. Ein Hardwaredefekt ist es wohl nicht, da "mplayer -vc ffh264vdpau -vo vdpau" ein Testfile problemlos abspielen kann, auch im Vollbild. Ich könnte da jetzt schrittweise wieder alles deinstallieren, aber kennt ihr da übliche Verdächtige?

    Gruß
    Henning

    Quote

    Mit der GF 9400 ?


    Nvidia ION, also GF 9400M.

    Quote

    Mit softhddevice z.b mit dem deinterlacer bob sollte es aber nicht ruckeln.
    Wenn doch hast du eher ein Softwareproblem.


    Das scheint mir so. So oder so, es geht nicht. Ich werde demnächst nochmal eine andere Hardware ausprobieren.

    Ich musste den X-Server mit einer statischen xorg.conf auf 50Hz konfigurieren, nodm installieren um den User vdr automatisch einloggen zu lassen (damit kein "xhost +" benötigt wird) und mir die richtigen Optionen für die plugins.softhddevice.conf zusammengooglen. Das würde ich alles nicht als idiotensichere Lösung ansehen.

    Ich hatte früher ( 2003-2008 ) eine DXR3 als Ausgabedevice laufen - sogar die war weniger fummelig einzurichten. :)

    Gruß
    Henning

    Die 91°C-Kiste ist mein Testsystem, ITX passiv gekühlt. Die FF-Karten liefen in meinem Produktivsystem, einem Standard-Tower-Gehäuse mit temperaturgeregeltem Netzteillüfter und aktiv gekühlter CPU.

    Um die Spannungen messen zu können, müsste ich mir auf der Arbeit erst einmal "lose" ein Mainboard hinstellen, Messequipment wäre da vorhanden. Dafür mangelt es jedoch an der Zeit.

    Gruß
    Henning

    Läuft dein X-Server schon mit 50Hz?


    Ja, mittlerweile.

    Was ist das für ein System?


    Ein 64bit Debian Wheezy mit e-tobi-Paketen.

    falls du ffmpeg selbst baust - ist die VDPAU-Unterstützung aktiviert?


    Das ffmpeg ist von deb-multimedia.org und wohl leider ohne VDPAU-Unterstützung. Ich zieh aber gerade die Sourcen des Pakets und die Build-Dependencies, um ein deb mit VDPAU-Unterstützung zu backen (ich hasse es wie die Pest, Software an der Paketverwaltung vorbei zu installieren). Hätte ich eine 64bit-Wheezy-VM auf meinem Desktop würde ich das darin machen, der Atom ist ein wenig schwachbrüstig dafür.

    Ich melde mich, sobald es Neuigkeiten gibt.

    Ach ja, ganz oben im Thread schrieb rudirabbit:

    Quote from rudirabbit

    normalerweise gibt es keinen Grund diese Karten noch zu verwenden.


    Doch. Genau diesen.

    Gruß
    Henning

    Das Gehäuse http://www.maxpoint.de/de/products/cases.php?pid=1_1_1&we_objectID=1193 sieht keine aktive Lüfungsmöglichkeit vor. Ich könnte das Slimlinelaufwerk ausbauen und einen Lüfter auf den Kühlkörper spaxen, aber ich bin mir nicht sicher, ob die GPU dann höher taktet. Angeblich soll das Zotac IONITX B ja 450Hz GPU-Takt erlauben, aber das sah in den nvidia-settings nicht danach aus.


    So, Deckel ab, 80mm-Lüfter auf Kühlkörper gelegt, nochmal probiert: 33°C GPU-Temperatur, 450MHz GPU-Takt, aber es ruckelt noch immer, selbst mit

    Code
    softhddevice.576i.Deinterlace = 0


    gibt noch haufenweise

    Code
    Apr 14 21:30:53 wheezy vdr: video/vdpau: missed frame (1328/2536)
    Apr 14 21:30:53 wheezy vdr: video: slow down video, duping frame


    Auch 720p ruckelt ein wenig.

    Gruß
    Henning

    Warum steht dann das in der Beschreibung?

    Das bedeutet sinngemäß "einen kleinen Heuler könnte man wohl irgendwo hineinfummeln und mit Kabelbindern befestigt bekommen, wenn mann denn einen findet, der klein genug ist, dass er nicht mit dem Mainboard kollidiert". Da ist keinerlei offizielle Befestigungsmöglichkeit. Der Satz dient nur der Rechtfertigung des Herstellers.


    Ich verstehe nicht, dass man überhaupt ein System betreibt, in dem Komponenten so heiß werden können... Wenn einem das nach dem Zusammenbau auffällt verbessert man die Kühlung normalerweise so lange, bis die Temperaturen in einem Bereich sind, in dem Bauteile langfristig überleben können :rolleyes:


    Ganz einfach: Ich hatte seit 2009 bis gestern noch nie nachgesehen, wie heiß die Kiste läuft, da im (gelegentlichen) Desktopbetrieb mit Windows XP und openSUSE 12.1 keinerlei Auffälligkeiten zutage traten. Außerdem hatte ich in der Vergangenheit auch schon passiv gekühlte Systeme im Einsatz, bei denen nie etwas schief gegangen ist, bspw. ein Celeron 220-ITX-Board und einen untertakteten AMD Geode NX1750 auf einem stinknormalen Sockel-A-Board (mein langjähriger Produktiv-VDR).

    Gruß
    Henning


    Wieso "selbst mit"? Das ist doch der heftigste Interlacer, das wundert jetzt kaum, dass das nichts wird.

    Es klotzt und ruckelt auch nur mit "temporal", und selbst 720p ohne jegliches Deinterlacing ruckelt. Die 9200 läuft dem nvidia-settings-Tool zufolge nämlich nur mit 200MHz GPU-Takt und wird dabei schon 91°C heiß. Das wird also nichts auf dem ION ITX-System.

    Ich werde irgendwann noch einen Versuch mit einer Geforce 9400 starten.

    Gruß
    Henning

    Seltsam, eigentlicht ist temporal schon ausreichend. Hast du am TV irgendwas im HDMI Betrieb aktiv was dir das Bild "verschlimmbesssert"?

    Ich hab das softhddevice-Plugin jetzt mal mit vdr-2.0.0 von e-tobi getestet. Soll mir ja keiner vorwerfen, ich hätte es nicht probiert. :)

    Mein Fazit: Bild klotzig und ruckelig, selbst mit temporal_spatial-Option. Das Plugin meldet zwar

    Code
    Apr 13 20:28:39 wheezy vdr: video/vdpau: VDPAU API version: 1
    Apr 13 20:28:39 wheezy vdr: video/vdpau: VDPAU information: NVIDIA VDPAU Driver Shared Library  304.88  Wed Mar 27 14:49:27 PDT 2013
    Apr 13 20:28:39 wheezy vdr: video/vdpau: high quality scaling unsupported
    Apr 13 20:28:39 wheezy vdr: video/vdpau: feature deinterlace temporal supported
    Apr 13 20:28:39 wheezy vdr: video/vdpau: feature deinterlace temporal spatial supported
    Apr 13 20:28:39 wheezy vdr: video/vdpau: attribute skip chroma deinterlace supported
    Apr 13 20:28:39 wheezy vdr: video/vdpau: 4:2:0 chroma format with 4096x4096 supported
    Apr 13 20:28:39 wheezy vdr: video/vdpau: 4:2:2 chroma format with 4096x4096 supported
    Apr 13 20:28:39 wheezy vdr: video/vdpau: 8bit BGRA format with 8192x8192 supported
    Apr 13 20:28:39 wheezy vdr: video/vdpau: 10bit RGBA format with 8192x8192 supported


    aber die zigfachen

    Code
    Apr 13 20:28:41 wheezy vdr: video/vdpau: missed frame (13/16)
    Apr 13 20:28:41 wheezy vdr: video: speed up video, droping frame


    pro Sekunde (!) wollen mir wohl sagen, dass die Geforce 9200 das wohl doch nicht leisten kann. Schade. Abgesehen davon fand ich Einrichtung des Frontends inkl. Autostart nicht weniger fummelig als mit xineliboutput (-x kann X-Server aus irgend einem Grund nicht starten, "xhost +" nötig, wenn nicht User vdr sich in DM einloggt, nachträgliches "svdrpsend plug softhddevice atta" notwendig etc.)

    Also bleibe ich vorerst bei der FF-Karte. Sorry, Leute. :)

    Gruß
    Henning

    Das mit dem softhddevice klingt schon mal sehr gut, danke. Ich musste mir zuletzt was mit selbstgeschriebenen Initskripten, "su"- und XAUTHORITY-Tricksereien zurechtbiegen, das hat meine ästhetischen Anforderungen nicht erfüllt. :)

    Getestet hatte ich auf einem ION ITX-System mit Nvidia 9200, und WIMRE hatte ich dem Xine-Frontend auch die temporal_spatial-Option mitgegeben. Das "Produktivsystem" hätte eine 9400 für den Zweck eingebaut.

    Gruß
    Henning

    Naja, das ist mein "Produktivsystem", das muss einfach funktionieren und ist seit Jahren im Wesentlichen unverändert, daher musste schnell Ersatz her.

    Ich habe auch noch ein Testsystem mit xineliboutput und VDPAU-Beschleunigung, aber das hat mir dahingehend nicht gefallen, dass das Deinterlacing beim Hochskalieren von SD auf 1080p lausig war. Ich bin verwöhnt vom Deinterlacer in meinem Fernseher (Samsung LE32B650), daher führe ich ihm SD-Material am liebsten unskaliert, über einen FBAS-Eingang zu.

    Außerdem hatte ich 2011 keine komfortable Lösung gefunden, X-Server und Xine-Frontend automatisiert beim Boot zu starten. Gibts da mittlerweile was idiotensicheres?

    Ich will aber demnächst mit VDR 2.0.0 einen neuen Versuch wagen. Was mich auch vom Upgrade abhält ist die Tatsache, dass ich in die Sourcen des Input-Treibers der TTPCI eine andere Keymap für den IR-Empfänger hineingepatcht hatte, um die Fernbedienung der PVRUSB2 am IR-Empfänger der FF nutzen zu können. IR-Empfänger der PVRUSB2 und LIRC waren mir nämlich beide zu träge, dahin möchte ich nicht mehr zurück. Die Alternative wäre natürlich eine neue Fernbedienung mit ähnlicher Tastenanzahl.

    Der wichtigste Punkt ist aber: Ich habe einfach nicht mehr die Zeit zum Basteln. Das Zeug muss einfach funktionieren.

    Gruß
    Henning

    P.S.: Das Teil ist ein stinknormaler Tower-PC mit Netzteil- und CPU-Lüfter (Sempron 140 boxed), da sollte zumindest nichts extrem überhitzen.

    Hallo Forum,

    ich bin seit ca. 10 Jahren vergleichsweise zufriedener VDR-User, seit 2008 auch mit DVB-C. Und das ist auch genau das Problem: Meine 2008 angeschaffte TT C-2300 starb im Jahr 2010 mit dem bekannten "ARM crashed" / "ARM boot failed"-Problem. Der vorgeschlagene Tausch der Kerkos auf 100pF/47pF brachte keine permanente Abhilfe, sondern verringerte nur die Häufigkeit des Auftretens des Problems. Ich kaufte mir darauf hin eine neue (für 40EUR), die bis letzte Woche lief und dann mit dem selben Symptom ausstieg. Nachbestückung der 27pF am Oszillator verhalf auch hier nur zu einer Milderung des Problems, und Verdoppelung des 100nF-Stützkondensators der Varicap-Steuerspannung auf 200nF (bei der Karte, die ich bereits 2010 wiederzubeleben versucht hatte), half dieser auch nicht. Also läuft mittlerweile bei mir die dritte TT C-2300, die neu wenigstens nur noch 20EUR gekostet hat.

    Ich frage mich: Was altert da so extrem, dass die Dinger nach 2 Jahren hinüber sind? Der Oszillator allein kann es ja nicht sein. Mir ist aufgefallen, dass die Karte von 2008 nach dem Wiedereinsetzen in Mainboard mehrfach nicht erkannt worden ist, oder nur fehlerhaft, mit PCI Device Class 0xFFFF oder Revision 0xFF, oder andere Einträge in "lspci -vn" waren grob falsch. Reinigen der Kontakte am PCI-Steckverbinder hat da geholfen.

    Ich muss allerdings eingestehen, dass mein VDR schon ziemlich dicht gepackt ist, die C-2300 sitzt zwischen GeForce 9400 und einer Lorenzen SL DVB-T PCI, und eine TT C-1501 sitzt auch noch in der Kiste. Wenn das thermisch was leidet, würde mich das nicht wundern. Allerdings sitzen auf der C-2300 ja fast ausschließlich Tantal-Elkos, und keine Feuchtelektrolytkondensatoren.

    Gruß
    Henning