Beiträge von Hemonu

    Ich habe zwei verschiedene Fernsehr per HDMI in Betrieb. Der Full-HD Plasma bringt das beste Bild native mit 1080p betrieben. Allerdings erfolgt im Fernseher auch noch eine Umrechnung / Interpolation auf 100 Hz. Das Bild kann sich mit jeder Box messen.
    Der zweite Fernsehr ist (wie viele Geräte) über HDMI nicht mit seiner native Auflösung ( 1366x768 ) sondern nur 720p oder 1080i anzusteuern. 720p mit temporal oder temporal-spatial ist eindeutig besser als 1080i.
    Wegen der modelines kann ich nur empfehlen, in der xorg.conf das mode-debugging einzuschalten. Dann findet man im Xorg.0.log alle Modelines, die der Fernseher wirklich unterstützt. Man kann mit nvidia-settings die EDID-Daten aus dem Gerät extrahieren und die Datei in der xorg.conf referenzieren und mit Modes 1920x1080_50, 1920x1080_50i oder 1280x720_50 findet der VDR selbst bei ausgeschaltetem Fernseher die optimale Modeline für das Gerät.


    Gruss


    hemonu

    Zitat

    Original von berniejonnie
    Jetzt versuche ich das auch unter lenny, das downloaden der Pakete base, driver, utils etc geht ja ganz gut, aber das make funktioniert nicht out of the box..... wie komme ich jetzt voran ? Hat jemand Erfahrung ?
    /BJ


    Ich habe das mehrmals unter Lenny gemacht. Das funktionierte auch, aber die Abhängigkeiten müssen manuell aufgelöst werden. Achte mal bei den Fehlermeldungen auf fehlende lib's. Dann googlen, zu welchem Debian-Paket die gehören und das entsprechende dev-Paket installieren. Dann sollte es eigentlich funktionieren.
    Für die Funktion sollte die Aktualisierung der alsa-driver meistens reichen. S/PDIF geht auch mit alsa 1.0.17, es kann aber sein, dass dein Audio-Chip noch nicht unterstützt wurde.


    Gruss


    hemonu

    Zitat

    Original von wbreu
    - Sound beim Umschalten ohne Knacken oder sonstwas


    - Die Klötzchen dürften ne Einstellung in xine-Plugin mit den Buffern sein.


    Gruß
    Wolfgang


    Buffers hilft wahrscheinlich auch bei den Soundproblemen. Ich fahre auf drei verschiedenen Rechner mit xineliboutput. Am empfindlichsten ist bei mir Digitalsound-Wiedergabe über den DD-Receiver. Eine Erhöhung der AudioBuffers auf 5000 brachte aber deutlich Entspannung. Allerdings spielt der Audio-Dekoder im Receiver oder Fernseher auch eine Rolle. Es kommt immer zu einem Bruch im Soundsignal beim Kanalwechsel. Manche Receiver muten andere geben leider ein Knacksen wieder.


    Gruss


    hemonu

    Zitat

    Original von infinite
    gibt es eigtl auch schon fertige debian pakete, die xinelib mit vdpau unterstuetzung mitbringen?
    nicht dass ich das patchen scheue, viel mehr gibt es xinelib 1.2 anscheinend nur in der experimental variante von debian, und die wuerd ich mir auf meinem produktiv vdr eigtl nicht so gerne antun.


    infni


    Die xine-vdpau 1.16 aus dem svn ist ein Debian-Quellpaket. Zumindest unter Ubuntu 8.10 kann man alle Abhängigkeiten auflösen und dann mit dpkg-buildpackage ein Debian-Paket bauen. Unter Lenny habe ich mir allerdings die Zähne ausgebissen:(
    Paket installieren, xineliboutput neu kompilieren (geht auch mit dem Hanno/etobi Quellpaket), installieren und voila.


    hemonu

    Zitat

    Original von durchflieger
    Es wäre mal interessant wie die FF-Karten die Synchronisation genau machen. Die funktioniert ja bekannter maßen hervorragend. Sowie mir bekannt ist dort die "Master clock" per Hardware regelbar. Hier wäre interresant wie denn genau die Regelspannung gewonnen wird. Auch nur durch Überwachung des Puffersfüllstandes des DVB-Stream oder vielleicht doch durch eine Art Taktrückgewinnung?


    Das läuft aufs gleiche hinaus. Da Puffereingang mit dem Datentakt und -ausgang mit Master clock erfolgt, ist die erste Ableitung des Pufferfüllstandes proportional der Frequenzdifferenz. Natürlich muss man die Reglerkonstante langsam genug wählen um stabil zu werden.


    Zitat

    Zukünftig dann so:
    Die xine "master clock" basiert weiterhin auf der "system clock".
    Im radeon Treiber können wir die aktuelle vertikale Position des crtc bestimmen und so einen offset zur system clock berechnen damit die ersten vpts direkt so liegen das die Frame/Fields genau zum richtigen Zeitpunkt kommen. Es wären dann keine Verzögerungsroutinen im Treiber mehr notwendig und insbesondere wäre der Einregelvorgang gleich null.
    Die vertikale Position wird weiterhin beobachtet und so der offset (=regelspannung) zur system clock korrigiert.
    Die "Regelspannung" die aus der Überwachung des Pufferfüllstand gewonnen wird dient jetzt direkt zur Nachregelung des Graka Timing in bekannter weise. Damit wäre der Regelkreis geschlossen.


    Den zweiten Teil würde ich bei einer NVIDIA Karte (wegen vdpau zur H264 Dekodierung) gegen eine Algorithmus ersetzen, der um ein Halbild verzögert/beschleunigt. Dann geht es auch ohne Eingriff in den Treiber. Wenn die Taktfrequenz der Grafikkarte genau genug eingestellt werden kann, dass das nur alle paar Minuten passiert, halte ich das für einen vertretbaren Kompromiss. Besser wäre natürlich, wenn wir den Takt frei verändern könten, aber dann müssten wir den Quarzoszillator gegen eine VCO ersetzen :(
    Weiss jemand wie genau man den Pixeltakt bei Radeon und NVIDIA einstellen kann ?
    Ich hätte evt. eine Idee, wie wir den Takt absolut messen können. Als Referenzsignal nehmen wir ein GPS-Zeitsignal und zählen die VBLANK-Interrupts. Wenn man lang genug laufen lässt, müsste man genau genug werden.


    hemonu

    Es gibt ja diverse Threads und einige ausgezeichnetes Patches, die sich mit der Verbesserung der VDR-Ausgabe über Grafikkarten beschäftigen. Ich möchte hier mal einen kleinen - mehr theoretischen - Denkanstoß geben, indem ich das Problem mal ein wenig aus der Sicht der Nachrichtentechnik beleuchte.


    Als die Digitalisierung in den Telefonnetzen Einzug hielt, stand man vor einem ähnlichen Problem, wir wir es haben. Wie sorgt man dafür, dass alle Multiplexer, Übertragungssysteme etc. so miteinander synchronisiert, werden, dass ein einziges Bit an Information verloren geht. Es gab zwei Möglichkeiten:


    a) synchrone Netze, d.h. alle Komponenten laufen mit dem selben Mastertakt und definierter Phasenlage


    b) plesiochrone Netze, d.h die Komponenten laufen alle mit ähnlichem Takt, der aber Toleranzen aufweist.


    Lösung a) ist enorm aufwendig, da die Verteilung des Taktes weltweit kaum möglich ist und daher immer nur Teilnetze wirklich synchron realisierbar sind.
    Man hat sich daher zu Anfang der Digitalnetze für ein plesiochrones System entschieden und erst viele Jahre später auf synchrone Netze umgestellt.
    Fernsehen ist insgesamt immer plesiochron. Es ist schlichtweg unmöglich, jede Außenkamera, die in eine Live-Sendung zugeschaltet wird, immer auf den Studiotakt zu synchronisieren. Natürlich treiben die Broadcaster schon einen sehr hohen Aufwand um so synchron wie möglich zu sein.
    Ich möchte daher unseren VDR mal mit einem plesiochronen Empfänger vergleichen:


    Als erstes muß ich im Empfänger eine Taktrückgewinnung aus dem Empfangssignal machen. Das erledigt die DVB-Karte. Dann wird das Empfangssignal mit diesem Takt abgetastet. Das abgetastete Signal geht durch einen Dejitterizer, in dem das Phasenrauschen des Taktes und Signales beseitigt wird. Danach erfolgt die Übergabe an die weitere Prozessstufen wie z.B. einem DeMultiplexer, die mit dem abweichenden lokalen Takt läuft. Die Anpassung erfolgt dadurch, dass innerhalb eines Rahmens sogenannte Stopfbits, die keine Signalinformation tragen, weggelassen oder hinzugefügt werden. Das gleiche machen sparkie und durchflieger mit ihren Patches letztendlich, indem sie die Blank- oder Synchronsignale verlängern bzw. verkürzen.
    Wo wir meines Erachtens Verbesserungspotential haben, ist bei der Taktrückgewinnung und dem Dejitterizer.
    Dazu möchte ich ein wenig rechnen. Die Toleranz für die Zeilen- und Bildfrequenzen im Fernsehsignal beträgt 10e-6. Wenn ich eine gleich genaue Videoausgabe hätte, wäre die maximale Abweichung 1 Halbbild in 166 Minuten ! Das bedeutet, es sollte grundsätzlich kein Problem sein, eine Grafikkarte selbst im Interlace-Mode frei laufen zu lassen. Man müsste nur ganz selten ein Halbbild fallen lassen oder verdoppeln. Selbst, wenn unsere Grafikkarte nur 10e-5 Genauigkeit hat, wäre ein Halbbild in 16 Minuten immer noch kein Problem. Die Praxis sieht ganz anders aus. Das Bild springt im Minutentakt, manchmal sogar im Sekundentakt, zwischen richtiger und falscher Field-order. Schaut man sich das Regelverhalten der durchflieger Patche an, sieht man, dass wir keineswegs eine konstanten Drift ausregeln, sondern es geht ziemlich hin und her. Eine Ursache dürften Schnitte und Übertragungsfehler im DVB-Signal sein, aber ich vermute, dass vor allem die schwankende Durchlaufzeit des Signals durch den VDR + xine +++ hier für viel Unruhe sorgt.
    Aus meiner Sicht sehe ich folgenden Weg für interessant an:


    1. Das Timing der Videoausgabe muß möglichst genau auf echte 50 Hz eingestellt werden. Dazu wäre es interessant, wenn wir mal messen würden, wie genau die Quarze auf den Karten wirklich sind, und evt. Abweichungen des Quarzes dauerhaft über die Modeline kompensieren.


    2. Der Mastertakt für die Ausgabe muss aus dem DVB-Signal der DVB-Karte gewonnen werden. Das könnte eventuell im Treiber oder möglichst früh im Signalweg des VDR erfolgen. Auf diesen Takt müssen wir unsere Ausgabe synchronisieren.


    3. Wenn wir einen vernünftigen Pufferspeicher für einige Frames so steuern, dass die Durchlaufzeit vom Mastertakt bis zur Videoausgabe konstant gehalten wird, bräuchten wir nur noch ab und zu (Halb-)Bilder zu verdoppeln oder löschen, um eine Regelung zu bekommen. Aufgrund der vielen beteiligten Software-Komponenten ist das nicht gerade trivial, würde dann aber auch z.B. mit vdpau funktionieren, ohne dass wir in den Treiber müssen.


    Ich hoffe auf eine lebhafte Diskussion :)


    hemonu

    Zitat

    Original von I30R6
    Wenn ich Stereo höre dann habe ich 1A Ton über HDMI an LCD . Bei DD allerdings am LCD nur knacksen aber am AV Receiver entsprechend DD 2.1/5.1.
    I30R6


    Die Fernseher können in der Regel nur Stereo 48k, 16 Bit dekodieren. Mit DD oder DTS könne die nichts anfangen


    hemonu

    Zur Nutzung des HDMI-Tons brauchst du ziemlich aktuelle ALSA-Treiber.
    Poste doch bitte mal die Ausgabe von


    aplay -l


    Dort müsste ein drittes Hardware-Device für den HDMI-Ton sichtbar sein, ansonsten update der ALSA-Treiber durchführen.


    MfG


    hemonu

    Ich den neuen Patch genau nach Anleitung im README unter Ubuntu 8.10 gebaut und installiert.


    # apt-cache policy xserver-xorg-video-radeon
    xserver-xorg-video-radeon:
    Installiert: 1:6.11.0-1
    Kandidat: 1:6.11.0-1
    Versions-Tabelle:
    *** 1:6.11.0-1 0
    100 /var/lib/dpkg/status
    1:6.9.0+git20081003.f9826a56-0ubuntu2.1 0
    500 http://de.archive.ubuntu.com intrepid-updates/main Packages
    1:6.9.0+git20081003.f9826a56-0ubuntu2 0
    500 http://de.archive.ubuntu.com intrepid/main Packages


    Trotzdem habe ich keine Regelung und im Xorg.0.log finde ich:


    (WW) RADEON(0): Option "FrameRateControl" is not used
    (WW) RADEON(0): Option "FrameRateVerbose" is not used


    Was ist denn da schief gegangen ? Der alte patch 0.91 funktionierte prinzipiell.


    hemonu

    Zitat

    Original von flump


    der prozess der die leistung verbrät ist "/usr/bin/X11/X :0 vt7 -dpi 100 -nolisten tcp


    lg, flump



    Trag mal in die xorg.conf in den Abschnitt Device eine zusätzliche Option ein:


    Option "UseEvents" "True"


    Das hat bei mir bei zwei Rechner geholfen. Die Prozessorlast wurde bei laufendem XServer allmählich immer größer, bis sie nach einigen Minuten fast 100% erreichte. Entsprechend drehte dann auch der Netzteillüfter auf.


    hemonu

    Hallo,


    ich nutze ein ABIT Mainboard mit NVIDIA 7050PV Grafik inkl. HDMI-Ausgang. An diesem Ausgang ist mein A/V-Receiver angeschlossen, an dem wiederum der Fernseher angeschlossen ist.
    Nachdem ich auf ALSA-Treiber 1.0.19 aktualisiert habe, ist im Mixer ein zweiter IEC958 Ausgang vorhanden und ich kann Ton über HDMI ausgeben. Allerdings gelingt mir das via xineliboutput und vdr-sxfe nur mit Stereoton, AC3 Passthrough will einfach nicht gelingen.
    Welchen Gerätename muß ich in der config_xineliboutput eintragen ?


    aplay -l:
    **** List of PLAYBACK Hardware Devices ****
    card 0: NVidia [HDA NVidia], device 0: ALC888 Analog [ALC888 Analog]
    Subdevices: 1/1
    Subdevice #0: subdevice #0
    card 0: NVidia [HDA NVidia], device 1: ALC888 Digital [ALC888 Digital]
    Subdevices: 1/1
    Subdevice #0: subdevice #0
    card 0: NVidia [HDA NVidia], device 3: NVIDIA HDMI [NVIDIA HDMI]
    Subdevices: 0/1
    Subdevice #0: subdevice #0


    meine asound.conf:
    pcm.!default hdmi


    pcm.hdmi {
    type hw
    card 0
    device 3
    }
    In der config_xineliboutput steht:
    # device used for mono output
    # string, default: default
    #audio.device.alsa_default_device:default


    # device used for stereo output
    # string, default: plug:front:default
    audio.device.alsa_front_device:default


    # alsa mixer device
    # string, default: PCM
    #audio.device.alsa_mixer_name:PCM


    # sound card can do mmap
    # bool, default: 0
    #audio.device.alsa_mmap_enable:0


    # device used for 5.1-channel output
    # string, default: iec958:AES0=0x6,AES1=0x82,AES2=0x0,AES3=0x2
    audio.device.alsa_passthrough_device:iec958:AES0=0x04,AES1=0x00,AES2=0x00,AES3=0x00


    Ich habe schon alles mögliche wie z.B. "iec958:CRD=0,DEV=3", "hdmi" etc versucht, aber entweder kein Ton oder der Ausgabe bleibt komplett stehen.


    hemonu

    Hallo Tobias,


    im Prinzip ja ..... aber:


    das funktioniert nur sinnvoll, wenn zumindest die Reihenfolge der Halbbilder korrekt und stabil ist. Das läßt sich erreichen mit bestimmten ATI- und Intel-Chipsätzen. Grundsätzlich geht das sowohl analog (siehe VGA2SCART) als auch per DVI/HDMI digital. Ein bißchen patchen und kompilieren ist aber notwendig. Du findest im Forum einige Beiträge, die das beschreiben.


    Willst du das vermeiden bzw. mit NVIDIA Grafik arbeiten, kommst Du um eine Vollbildausgabe nicht herum. Dann ist der Deinterlacer im PC für die Qualität sehr entscheidend. Du hast aber abhängig von der Rechenpower reichlich Auswahl.


    Ich bin gerade auf einen neuen Plasma (Panasonic TH-42PZ85) umgestiegen und habe an dem beide Varianten - VGA2SCART vom Intel-Board / HDMI vom NVIDIA-Board - getestet. Der Fernseher ist auch 100 Hz, das heißt das Bild wird noch einmal durchgerechnet und mit Zwischenbildern versehen.


    Mein Fazit:
    Das analoge Bild ist zunächst deutlich farbbetonter und kontrastreicher. Das liegt aber nur an den A/D und D/A Wandlern sowie den Einstellwerten für Helligkeit, Kontrast, Farbe und Gamma. Mit ein wenig Einstellen bekommt man für beide Varianten gleiche Charakteristiken hin. Dabei spielt der persönliche Geschmack (und Gewohnheit) eine große Rolle. Ein Bild was der eine als zu poppig empfindet, wird jemand anderes als zu fahl und kontrastarm bezeichnen.
    Bezüglich Schärfe, Rauschen und Farbverläufen habe ich das beste Bild über HDMI + 100Hz, aber die viele Rechnerei generiert einen deutlich warnehmbaren SOAP-Effekt, wie es üblicherweise Fernsehstudio-Produktionen zeigen. Der Vordergrund wird knackig scharf, der Hintergrund wirkt etwas weich gezeichnet. Selbst eine Action-Szene aus einem James Bond erscheint ein wenig wie im Studio produziert. Die Perspektive ist irgendwie überbetont. Ich mag diese Darstellung, mein Sohn meint "Das Bild ist total künstlich".
    Den gleichen Effekt habe ich auch, wenn ich eine DVD aus meinen BD-Player per HDMI zuspiele. Schalte ich 100Hz ab, liegt der Bildeindruck irgendwo in der Mitte. Es liegt also nicht nur am VDR.
    Was mir noch fehlt ist: Zuspiel interlaced über HDMI und dann Deinterlacing im Fernseher oder A/V-Receiver. Werde ich mich auch noch rangeben, aber ich erwarte da nicht mehr viel Neues.
    Ein Flachbild-Fernseher hat einfach andere optische Eigenschaften und einen anderen zeitlichen Bildablauf als ein Röhrenfernseher (für den interlaced interlaced Fernsehen konzipiert ist) oder ein Kino-Projektor (für den 24p Filme entworfen sind).
    Nicht warnehmbar ist übrigend, ob die Skalierung auf 1080 Zeilen im PC oder im Fernseher gemacht wird. Das OSD ist aber viel besser, wenn der PC 1080p statt 576p ausgibt.
    Man muß also immer Kompromisse akzeptieren und selbiger muß zu deinem persönlichen Geschmack passen. Der digitale Weg gibt einem dabei insgesamt mehr Einstellmöglichkeiten.


    Gruss


    hemonu

    Zitat

    Original von ciax
    .. hab nochmal im nvnews-forum gefragt. lt. meinung eines xine-vdpau entwicklers, stellt sich für ihn die sache folgend dar:



    so klingt das auch für mich logisch :monster1


    Was letztendlich heißt, dass ein AMD-Board mit einer einfache NVIDIA-Karte im PCI-E doch die günstigste Lösung sein sollte.


    hemonu