Nachziehen von VDR am TV

Hallo,
... nur Gedanken

- lcd 50 hz Kompatibilität
- Grafiktreiber howto/Xv suchen

bis dann,
Nando

Falls du der Röhre direkt das RGB Signal futterst tippe ichauf ein Problem mit dem deinterlaceing der Halbbilder - entgegen der allgemeinen Erwartung musst du deinterlacing selbst dann aktivieren, wenn du direkt ab Grafikkarte auf eine herkömmliche Tv Röhre gehst. Das Bild wird also im Grafikkartenspeicher kurz deinterlaced und dann als Halbbilder wieder herausgegeben. Also kurz in xine nachschauen, ob deinterlaceing bei dir aktiv ist und mit welcher Methode.

Mehr dazu im vga2scart Thread

Ich sag ja es tönt im ersten Moment unlogisch - wirf das Deinterlacing einfach mal an und staune wie ich es getan habe. Ist schwierig zu sagen wo es genau bei vielen Grafikkarten hackt, aber die Videotimeings stimmen offensichtlich bei raschen Bewegungen nicht mehr.

Ich habs durch Deinterlacing gelöst und durch's verwenden von Nvidia Karten. Deren Closed Source Treiber für Linux beherrschen das exakte Timing auf die Tv Austastlücke am besten.

Mehr dazu im Vga2scart Thread - Sparkie durchschaut das sicher genauer als ich.

Zitat

Originally posted by Romsky
Hmm... deinterlacing ist deaktiviert. TV ist angeschlossen via SVIDEO.

Aber iegentlich würde es doch keinen Sinn ergeben zu deinterlacen.....denn:

TV-Signal--->Interlaced----->Deinterlacing------>Interlacing------->TV (mein RöhrenTV kann leider nur Interlaced, wie eigentlich jeder RöhrenTV)

soweit die Theorie.
Der Datenpfad, insbesondere wenn du S-Video verwendest sieht leider anders aus. Der TV-Encoder sieht nur einen 'progressive' Framebuffer, aus dem er die Daten bezieht. Er kennt die Quelle aus der die Daten stammen nicht. Deswegen kann hier auch keine zeitliche Synchronisation mit dem Quellmaterial mehr erfolgen. Das ist natuerlich kein Problem solange nur die CPU z.B. mit Desktop-Grafik im Framebuffer zeichnet, dem Haupteinsatzzweck von Grafikarten. Fuer uns ist es aber reichlich unbrauchbar. Darum verwende ich auch kein S-Video.

=> es muss also auch hier deinterlaced werden, wie Lou bereits gesagt hat

PS: Der vga2scart Thread ist hier nicht so nuetzlich, da er sich nicht mit S-Video sondern mit der Erzeugung von RGB- aus VGA Signalen beschaeftigt.

Zitat

Originally posted by Romsky
[quote]das bei manchen Bewegungen (egal ob schnell oder langsam) vor allem bei Nahaufnahmenn das Video nachzieht. (also das Live Bild). Bei Filmen welche ich mit Xine-lib wiedergebe ist das nicht so.

diesen Unterschied verstehe ich nicht. Vielleicht ist bei dir noch irgendein anderer Effekt im SPiel. WIe gibtst du denn 'das Live Bild' wieder? Nicht mit xineliboutput?

sparkie: ist es nicht letztendlich nicht ein einziges riesiges Treiber Dillema? Die Hersteller von Grafikkarten verfolgen ja sicher auch den Tv Markt mit aufmerksamen Augen: moderne auf LCD TV optimierte Flachmänner kommen immer besser mit progressivem Bildmatrial zurecht. Bei all dem Kosten/- und Zeitdruck kümmern sich die Hersteller von Grafikkaten doch schlicht und ergreifend um andere Dinge als um veraltetes Tv Interlaceing, welches ohnehin kein moderner Pc Monitor mehr unterstüzt. So sieht's doch aus! ... traurig aber wahr...

Den "interlaced Markt" überlässt man den Herstellern von Settop Boxen und Mediacenter komplett Bausätzen wie Digitainer etc.

Eigentlich schade, aber auch bei mir ist schon ganz klar die Entscheidung gefallen: lebt meine Tv Röhre ab kommt ein Flachmann als Ersatz her, der schon nen RGB/HDMI/DVI Anschluss hat und damit saubere bewegte Vollbilder ausgeben kann. Das ist dann quasi ein auf Tv optimierter Monitor. Die Röhre ist wie das analoge Fernsehen ein Auslaufmodell.

Ohne Zweifel ist die Röhre beim interlaced Verfahren jedem LCD überlegen, nur ist interlaced schon vor ner Ewigkeit aus der Pc Welt verbannt worden. Die LCD Tv Hersteller reissen sich ihrerseits alle die Beine aus, vernünftig damit umgehen zu können. Die Zukunft soll nunmal progressiver Bildaufbau sein (24p) - auch deswegen, weil die Kapazitätsprobleme im DVB Standart dank MPEG Kompression verschwunden sind.

Bei mir war's jedenfalls die reinste Odyssee, bis vga2scart auf der Röhre gut gelaufen ist. Da braucht man kein Genie zu sein um zu erkennen, wie problemlos das bei nem Flachmann gelaufen wäre. Aber deswegen lauf ich jetzt nicht in den nächsten Laden und kauf mir ohne Notwendigkeit einen.

Zitat

Originally posted by Lou
Da braucht man kein Genie zu sein um zu erkennen, wie problemlos das bei nem Flachmann gelaufen wäre. Aber deswegen lauf ich jetzt nicht in den nächsten Laden und kauf mir ohne Notwendigkeit einen.

trotzdem warten auch hier schon die naechsten Fallstricke auf den Kaeufer. Z.B. weil die meisten 'Flachmaenner' mit 60Hz native Refresh fuer die grossen Absatzmaerkte mit NTSC-Farbuebertragungssystem gebaut werden. Europa mit 50Hz (PAL) wird da erst mal hinten angestellt.

Zitat

Originally posted by Lou
sparkie: ist es nicht letztendlich nicht ein einziges riesiges Treiber Dillema?

das Treiberdilemma wiederum kommt vielfach daher, weil viele Hersteller keine Specs fuer ihre Hardware herausgeben. Linux ist fuer die halt kein interessanter Markt.

Umso erstaunlicher, wie gut unter LInux vieles von dem laeuft, das letztlich nur durch Reverse Engineering entwickelt werden konnte.

Zitat

Originally posted by sparkie
trotzdem warten auch hier schon die naechsten Fallstricke auf den Kaeufer. Z.B. weil die meisten 'Flachmaenner' mit 60Hz native Refresh fuer die grossen Absatzmaerkte mit NTSC-Farbuebertragungssystem gebaut werden. Europa mit 50Hz (PAL) wird da erst mal hinten angestellt.

davon hab ich auch gelesen - wobei: berechnen die heutigen Flachmänner mit 100Hz Technik nicht selber noch interpolierte Zwischenbilder, um jegliches Ruckeln bei bewegten Szenen aus zu merzen? Bei HD Content machen sie's zumindest - das sind wahre "Grafikrechenmonster" geworden ... warum dann nicht bei SD?

Ich würd den Flachmann auch nur noch mit deinterlaceten Vollbildern füttern, die Grafikkarte könnte allenfalls ja selber noch ein paar zusätzliche Frames dazurechnen - das stellt sie vor keine hardwaretechnischen Probleme.

Ich seh da erneut keine Hardware/- sondern nur Softwareprobleme - das Ganze läuft nicht "Hand in Hand wie geschmiert" wegen mittelmässiger Soft aus den Gründen die du genannt hast: Linux ist denen zuviel Aufwand, Open Source ist der Teufel in Person... schade!

Romsky:
wenn es darum geht, einen traditionellen TV an einer Grafikkarte zu betreiben, wuerde ich in jedem Fall die VGA->RGB Methode, statt TV-OUT bevorzugen. Das haben wir speziell fuer manche ATI Karten/Chips u.a. in diesen Threads beschrieben. Da die ATIs das erforderliche Composite-Sync Signal direkt erzeugen koennen, reduziert sich hier der Schaltungsaufwand auf ein Kabel mit ganzen 2 Widerstaenden.

Bei nVidia und anderen Karten hilft eine verallgemeinerte Variante des VGA->RGB Kabels, welches in diesem Thread sehr detailliert (sogar mit Teileliste fuer Reichelt ) beschrieben ist. Das Composite-Sync Signal wird hier mit einer kleinen externen Zusatzschaltung erzeugt.

Die VGA->RGB Methode hat u.a. den Vorteil, dass das Timing vorgegeben durch den Xserver direkt den Elektronenstrahl des TV steuert. Es sind also keine TV-Encoder mehr im SPiel, die durch eigene Skalierung oder zusaetzliche Bandbreitenbegrenzung des Videosignales die Bildqualitaet verschlechtern. Der Xserver laeuft direkt mit der Aufloesung 720x576 Pixel (interlaced). Die Konfiguration ist ansonsten weitgehend gleich, wie fuer den Betrieb eines VGA/DVI Displays. Es wird also auch hier deinterlaced und skaliert wird ausschliesslich ueber die Xv-Extension im Xserver. Bei nVidia Xservern ist Synchronisation des Frameupdate auf die vertikale Austastluecke ohne zusaetzliche Patches schon vorgesehen => voellig fluessige Bilddarstellung wie bei einer FF wird moeglich.

zum Quali-Unterschied zwischen S-VIDEO und VGA->RGB siehe auch diesen Post