Beiträge von hddummy

    Hallo,


    ich hatte folgendes Problem:


    Da ich den WAREAGLE-Patch für die schöneren Symbole aktivert hatte, musste ich die Umgebungsvariablen auf UTF-8 stellen.


    Die EPG-Daten (epg.data) lagen jedoch nach wie vor als ISO-8859-1 vor.


    Mit der Installation des tvm2vdr-Plugins wurden die "externen" EPG-Daten als UTF-8 eingefügt,
    welches bei mir zu Problemen mit den Umlauten geführt hatte.


    im SYSLOG war folgende Zeile zu finden


    Zitat

    .... TVM2VDR: loading stylesheet ../etc/conf/plugins/tvm2vdr/tvm2vdr_tvmovie-utf-8.xsl


    also sah ich mir diese Datei an und änderte die Zeile


    Zitat

    <xsl:output method="text" omit-xml-declaration="yes" encoding='utf-8'/>


    in


    Zitat

    <xsl:output method="text" omit-xml-declaration="yes" encoding='iso-8859-1'/>


    Danach habe ich die EPG-Daten und die Verszeichnisse xml und epgimages (angelegt von tvm2vdr) gelöscht. Nach dem wieder alle EPG-Informationen erneuert wurden und das tvm2vdr-Plugin alles auf den aktuellen Stand gebracht hatte, war das Umlaute-Problem weg.


    Ich weiß - das ist absolut "quick and dirty" aber bei mir hat es geholfen.


    Viele Grüße :unsch


    Erik


    Ich habe das alles noch einmal getestet. Über DVI/HDMI funktioniert das alles. Über HDMI ist nur der Beamer angeschlossen. Der ist insbesondere für HD-Filme.
    Ansonsten nutze ich noch die alte Röhre, da es so viele HD-Sendungen ja auch nicht gibt. Es klappt ja auch alles prinzipiell - allerdings für den TV nur mit


    Option "Composite" "Enable"


    und daher mit tearing. Selbst die herunterscalierten HD-Sendungen wirken auf der Röhre klarer als das Mpeg2-Material .Mit der


    Option "Composite" "Disable"


    kommt der aufgeführte Fehler mit TV "xorg.conf" reproduzierbar vor.


    Mit Deinterlacing hat das alles nichts zu tun !


    Könnt Ihr diese Erfahrungen bestätigen ? Haltet Ihr das für ein Treiber-Problem, oder habt Ihr noch eine Idee ?


    Gruß


    Erik

    Vielen Dank für die schnelle Antwort.


    Mit der Option "Composite" "Disable" bleibt das Wiedergabefenster bei xine-vdpau, xinelibout schwarz und mit mplayer-vdpau-3263604 grün .Nur den Ton kann man Hören.
    Im Syslog bekomme ich dann einmalig folgende Fehlermeldung bis kdm neu gestartet wird:


    ... kernel: NVRM: Xid (0001:00): 62, CMDre 00000003 000000e4 011e0000 00000004 00000084


    Dies ist reproduzierbar. Ich habe den Kernel Treiber 180.18 und den mplayer noch einmal neu übersetzt. Dies hat bei mir jedoch keine Besserung gebracht. Ich konnte es bis jetzt allerding nur mit dem TV-probieren.
    Hier mal meine xorg.conf:



    Wenn ich "Composite" auf "Enable" setzte funktioniert es zwar aber nur mit tearing.


    Hat da vielleicht jemand von Euch eine Idee, oder das gleiche Problem ?


    Was mache ich falsch, oder ist das ein Treiberproblem ?

    Hi,


    ich hab mal wieder ein paar Fragen.


    1. habt Ihr noch die tearing-Probleme bzgl. VDPAU ?


    Bei mir sieht es so aus, dass über S-Video wie auch HDMI (für beides gilt: nvidia-settings -> 50 Hz
    Vertical Refresh-Rate) nach wie vor das störende tearing auftritt.
    Ich verwende zwei unterschiedliche "xorg.conf" wobei jeweils nur ein Anschluss aktiv wird.


    2. Wie sieht das z.Zt. bei xine-vdpau mit dem deinterlacing aus ?
    Wird das schon über VDPAU realisiert, oder findet das noch in SW statt ?
    Wenn ich das richtig verstanden habe wird dies mittlerer Weile von VDPAU unterstützt.


    Vielen Dank schon einmal.

    Hallo,


    ich habe auch mal den Trailer iceage von apple.com in 720p und 1080p versucht. Beide laufen bei mir einwandfrei.


    Mit dem Test-Schnipsel oceans.thirteen.2007.720p.hddvd.x264.sample-sinners.mkv von Matroska Container und HD/E habe ich ein ganz seltsames Phänomen:


    Die ersten Sekunden sind OK. Danach entsteht mir der Einduck, als ob sich der Hintergrund vom Vodergrund löst und "unabhängig" voneinander in der Zeit zurück und vor springt. Ohne VDPAU, also rein in SW, funktioniert das ohne Probleme.
    Mit welchen Test-Schnipse habt ihr Probleme. Vielleicht kann man diese nach Format-Varianten sortieren und die Probleme dann im Nvidia-Forum Posten.


    Habt Ihr eventuell 1080i (h.264) Schnipsel, die bei Euch gut funktionieren ?
    Mit euroHD scheint dies auch einer dierser Geschichten zu sein, die ohne I-Frames auskommt.


    Gruß


    Erik

    Hallo zusammen,


    mit dem neuen Treiber und der aktuellen Version vom mplayer-vdpau (ftp://download.nvidia.com/XFre…yer-vdpau-3219724.tar.bz2) hat sich vieles verbessert.


    Bei mir funktioniert jetzt auch die Wiedergabe von mpeg2-Material mittel -vc ffmpeg12vdpau. Mit den älteren Versionen hatte ich immer vertikale Streifenbildung im Bild.


    Ich habe jetzt auch kein h.264-Material mehr, welches grundsätzlich nicht mit ffh264vpau funktioniert. Mein Haupt-Problem ist z.Zt., dass h264 im 1080i-Format sehr Ruckelt. Ich habe den Eindruck, als würde jedes zweite Halbbild geschluckt. Hat Ihr auch dieses Problem ? Oder konntet Ihr das bereits lösen ?


    Als ein repräsentatives Beispiel möchte ich euroHD.h264 aus http://www.nvnews.net/vbulletin/showpost.php?p=1858497&postcount=196 anführen.


    Hat auch schon jemand Erfahrungen punkto deinterlacing und VDPAU gemacht ? Soviel ich weiß wird die HW-Lösung noch nicht unterstützt.


    Mein System:


    Core 2 Duo E8500 (3,16 GHz) / 4GB-RAM
    GeForce 8500 GT (512MB) (Treiber 180.16)
    Open Suse 11.0


    Vielen Dank


    Mit dlopen kenne ich mich nicht aus. Aber bei meinem mplayer hat es funktioniert. Wieso soll das auf anderen Systemen mit identischer Version anders aussehen ?
    "ldd" zeigt Libs incl. Pfade an die mittels linker dynamisch dazu gelinkt wurden.

    Der Compiler prüft generell nicht die HW.


    Der Compiler wird im configure-script nur verwendet, um herauszufinden, ob sich diese mini c-programm grundsätzlich übersetzten lässt. Ein Fehlschlagen kann auf Compiler-Probleme, ein Fehlen der libs oder header-Dateien, Schnittstellen problem (z.B. bei neuer Version), etc. deuten.
    Jenachdem werden diese Programme nach erfolgreichen Übersetzvorgang auch noch ausgeführt.


    In deinem Fall scheint dies eben nicht das Problem zu sein, sonst wäre VDPAU im "config.mak" nicht mit "yes" beantwortet worden.


    In deinem Fall wird die VDPAU nicht vom mplayer angezeigt. Ich gehe aber davon aus, dass VDPAU im mplayer mit drin ist, sonst hättest Du einen Fehler beim compilieren gehabt, das laut config.mak VDPAU mit integriert wird. Ich hab das jetzt mal mit meinem Notebook ausprobiert, welche keine VDPAU HW hat.
    Mplayer beinhaltet VDPAU-Unterstützung.


    Zitat

    cat mplayer | grep -i VDPAU



    Wenn dann


    Zitat

    Übereinstimmungen in Binärdatei (Standardeingabe).


    oder vergleichbares erscheint, wurde VDPAU mit compiliert.


    Ich gehe davon aus, das mplayer z.B. beim Start überprüft, welche Codecs (bzw. HW-Beschleunigung) mit der vorhandenen HW funktioniert.


    Hier hab ich noch mal einen Hinweis gefunden bzgl. 512 MB:


    http://www.nvnews.net/vbulletin/showpost.php?p=1859121&postcount=200


    Kannst Du wirklich nicht auf 512MB im BIOS umstellen ?

    Welcher Wert wird "CONFIG_VDPAU" im config.mak nach configure-Lauf zugewiesen.
    Vielleicht den "make" im checkout...-skript auskomentieren und bevor das "make" von Hand ausgeführt wird den "CONFIG_VDPAU" auf "Yes" setzten.


    Das würde auf einem Fehler im configure-script Hinweisen. Beim configure-skript wird oft ein kleines mini c-Programm übersetzt. Es könnte daher auch mit der compiler-Version zusammen hängen. Meine gcc-version ist 4.3.2 auf einem OpenSuse 11.0.


    Meist wird mit dem --enable-... nur als "Wunsch" interpretiert. Wenn beim Test festgestellt wird, dass diese Option - aus was für Gründen auch immer - nicht positiv bewertet werden kann, wird die Option zurückgesetzt. Dies hängt aber vom configure-skript ab, wie damit umgegangen wird. Daher muss die Option --enable-vdpau nicht auch automatisch bedeuten, dass der "Wunsch" auch angenommen wird. Dies kann man, wie bereits erwähnt in der Datei "config.mak" nach sehen.

    duc


    Ich gebe Dir generell Recht.


    Nur muss man auch beachten, das VDPAU noch in den Kinderschuhen steckt, und es durchaus sein kann, dass Bugs mit einer neunen Version ausgemerzt sein können, obwohl dies nicht offiziell beworben wird. Da in deinem Fall wahrscheinlich sowieso der Treiber etc. hätte mal neu installiert werden müssen, denke ich zumindest, sollte gleich ein Test mit dem neuen erfolgen, damit Andere das auf dem gleichen Stand reproduzieren können.


    Mit meiner Graka habe ich dieses Problem zumindest nicht.



    Ob VDPAU im mplayer mit comiliert wurde kannst Du an der Datei "config.mak" sehen. Einfach nach "CONFIG_VDPAU" suchen. Wenn da "Yes" steht wurde VDPAU zumindest mittels configure-skript erkannt. Vielleicht auch die entsprechende Stelle in diesem Script und "configure.log" mal ansehen, wie VDPAU verifiziert wird. Vielleicht klapt es sogar, wenn nach dem configure-Lauf "config.mak" manipuliert wird.


    Nur würde diese Theorie der Tatsache widersprechen, dass VDPAU bei den unterstützen Treibern angezeigt wird. Vielleicht werden die libs nicht gefunden ???? Dann könnte eventuell ldconfig helfen ?!?!?


    Gruß


    Erik

    Hallo,


    versuch es nochmal mit Treiber 180.11 .(http://www.nvnews.net/vbulletin/showthread.php?p=1861825)


    Es sollte dann funktionieren, Es könnte sein dass Du mplayer neu übersetzen musst.


    Mittels ffmgeg12vdpau (bei Mpeg2-Material) habe ich nach wie vor ein streifiges Bild. Ich denke, dass die Jungs von NVIDIA sich aber zunächst um h.264 kümmern werden.


    Gruß


    Erik


    P.S.: Bei der nächsten Treiber release soll das Problem bzgl. h.264 und Anzahl Ref-Frames gelöst werden. Hierzu wird die API leicht verändert, damit der Maximal-Wert mittels Applikation einstellbar ist.

    Zitat

    Originally posted by jerily
    ...


    Ich kann NVIDIA da schon verstehen, daß sie bei einem Neubeginn jetzt nicht diese Bastellösung mitschleppen wollen, die es nur gab weil sie damals nichts Vernünftiges hatten und bin eher froh, daß es da nun überhaupt etwas gibt.


    Nachdem die Hintergründe bekannt sind, macht es wirklich keinen Sinn dies mit biegen und brechen mit VDPAU zu Lösen. Deswegen habe ich diese Thematik auch von VDPAU abgelöst und sehe eher eine mögliche Lösungserarbeitung bei der Comunity.


    Nach der Aussage im NVIDIA-Forum wage ich sogar zu bezweifeln, ob NVIDIA überhaupt Hand bei dem Software-Part der gepriesenen HW-Beschleunigung anzulegen wird.
    Vielmehr gehe ich davon aus, dass dies mittels diverser Applikationen wie Mplayer und Co oder einem Zwischenlayer, wie es bei Windows DirectX ist, mit den vorhandenen Treibern gelöst werden kann.


    Ich habe überhaupt keine Ahnung von Shader-Programmierung, jedoch erscheint mir dies als ein möglicher Ansatz.


    Kann hier vielleicht Jemand eine Aufklärung geben, was Shaders bzgl. h264 leisten könnten, oder schon leisten ?

    Gruß


    Erik

    Hallo,


    mal wieder eine neuer Thread.
    Mit diesem Thread würde ich gerne erreich, dass Erfahrungen bzgl. der Wiedergabe verschiedensten HD-Materials gesammelt werden. Vielleicht hat Jemand bereits Erfahrungen mit diversen Playern oder sogar dem VDR gemacht. Hierzu sind natürlich auch Windows Nutzer eingeladen.
    Wichtig fände ich die Info, mit welcher HW diese Erfahrungen gesammelt wurden.


    Anlass für diesen Thread halte ich eine hier begonnene Diskussion


    http://www.vdrportal.de/board/…?postid=772583#post772583


    Hier noch die Zitate:


    Hallo,


    ...


    Bzgl. Geforce 6,7 und G80 gibt es schlechte Nachrichten.


    http://www.nvnews.net/vbulletin/showpost.php?p=1853112&postcount=14


    Die beworbene HW-Beschleunigung bzgl. h264 ist wohl sehr gering und wurde mittlels Shaders realisiert.
    Der Rest wird unter Windows wohl mittels DirectX erledigt. Es handelt sich wohl vielmehr um eine Marketing Darstellung ...


    http://www.nvnews.net/vbulletin/showpost.php?p=1853242&postcount=16


    Mittels VDPAU wird es da wohl auch nichts geben. Für mich hört sich das so an, als fast nicht andere übrig bleibt als DirectX zu analysieren... :angryfire[/quote]


    -----------


    Zitat

    Originally posted by jerily

    Oder eben eine neue Karte, die vollwertige Videoprozessoren hat. Eine G80 ist doch sowieso so ein Stromschlucker, sie in einem VDR einzusetzen paßt doch nicht gut zusammen. Die ganzen aktuellen 30/40/50€ LowEnd Chip und aktuellen IGPs scheinen alle vollwertige Videochips zu haben und können auch VC1.


    -----------------



    ---------------


    Zitat

    Originally posted by JK1974
    hddummy:
    Schlimmer noch - habe auch was, was ich in noch keinem Forum gelesen habe: Ich habe mit einer GeForce 7600 mal einen Full-HD-Film auf einem Full-HD-Screen wiedergeben wollen. Ergebnis: Seltsam "kantiges" Bild, als handle es sich um eine Skalierung über Pixelwiederholung. Gleicher Rechner, gleiches System, GeForce 8600: Alles ok.
    Seitdem behaupte ich: Alle Karten < GeForce 8 können kein Full-HD.
    P.S.: Bezieht sich natürlich auf Windoof...


    ------------



    So, dann viel Spaß.


    Gruß


    Erik :unsch

    Zitat

    Originally posted by jerily
    Oder eben eine neue Karte, die vollwertige Videoprozessoren hat. Eine G80 ist doch sowieso so ein Stromschlucker, sie in einem VDR einzusetzen paßt doch nicht gut zusammen. Die ganzen aktuellen 30/40/50€ LowEnd Chip und aktuellen IGPs scheinen alle vollwertige Videochips zu haben und können auch VC1.



    Sofern Du einen Media PC meinst, der die meiste Zeit läuft gebe ich Dir grundsätzlich Recht,
    Aber nicht für diejenigen, die sowieso eine Geforce 6/7 bzw. G80 Karte haben bzw. genau wegen der Hoffnung auf HD gekauft haben und dies nur hin und wieder nutzten wollen. Soviel HD-Material gibt es schließlich z.Zt. auch nicht.


    Sorry, es kann doch nicht sein, dass man mit HW-Beschleunigung wirbt, und dafür sich einen Großen Namen einfallen lässt, für etwas was so nicht existiert.
    In keinen einzigen Forum habe ich bis lang gelesen, dass sich das Jemand unter dem so beworbenen PureVideoHD vorgestellt hat.


    Dies mag man gerne an Nvidia, ATI und wahrscheinlich auch Andere adressieren...


    Aber bitte zurück zum Thema. Ich finde es nach wie vor Interessant, wenn auch ein Weg gefunden würde, der die ältere Genaration für HD vernünftig nutzbar macht.