[patch] RGB/PAL ueber VGA mit variabler Framerate

  • Zitat

    Originally posted by henfri
    warum dieser Patch nicht auch für den Anschluss per DVI nützlich wäre. Denn m.W. (aber ich kenne mich da nicht aus) unterstützen doch die meisten LCDs auch interlaced input (zumindest 1080i).


    das ist grundsaetzlich durchaus richtig! Die Frage ist hier, wie in welcher Aufloesung das Quellmaterial vorliegt. Falls dieses von der Grafik erst auf 1080i hochskaliert werden muss, duerfte es schwierig werden. Es muss ja die genaue Zuordnung der even und odd Fields von Quelle und Ziel erhalten bleiben - trotz unterschiedlicher Aufloesung.


    Das hier geschilderte Verfahren beruht im Moment darauf, dass die Fields einfach 1:1 vom Dekoder auf den VGA-Port durchgeschoben werden (insbes. OHNE vertikale Skalierung), was im Fall von PAL (i.e. 576i) relativ einfach ist (wenn auch mit ein paar inzwischen geloesten Tuecken).

  • Ein Ausschnitt meines Timing Debug (mit Version vga-sync-fields-0.0.5) von Live-TV ZDF 19:25 Die Rosenheim-Cops sieht wie folgt aus.


    - pro Sekunde erfolgt eine Messung == Linie
    - die gesamte Linie '-' repraesentiert das zur Verfuegung stehende 40ms Updatefenster fuer ein neues Frame
    - optimal kommt das neue Frame '|' genau mittig (Mitte ist gekennzeichnet durch '+')
    - die aktuell ermittelte Driftgeschwindigkeit (VGA gegen Stream) wird mit '*' gekennzeichnet.


    Die Regelung versucht die Driftgeschwindigkeit so zu beeinflussen, dass die neuen Frames bevorzugt in die Mitte eines 40ms Intervalles treffen. Und dass die Driftgeschwindigkeit im Mittel gegen Null geht (in dieser Prioritaet).


    Das funktioniert jetzt auch bei Live-TV schon recht gut.



  • Zitat

    dann ist ja die Frage, ob die LCD auch 576i können.
    Wenn ja, dann könnte man sich das Skalieren im VDR auch sparen.


    ueber SCART koennen sie das immer.
    Aber das haengt zu sehr vom EInzellfall ab wie *gut* die LCDs das koennen. Da hilft wahrscheinlich nur testen:)

  • Ja, aber die Frage ist, ob man ein Digitales Signal analog wandeln will nur um es dann wieder zu digitalisieren.


    Wie kann ich denn (einfach) testen, ob mein LCD über DVI mit 576i klar kommt?


    Gruß,
    Hendrik

  • Besteht denn irgendeine Chance, das an andere Chipsaetze anzupassen? Speziell der i830 der S100 waere dann ja praedestiniert fuer kleine Sat-Boxen mit gutem TV-Out (ueber VGA).

    VDR: ASUS AT3ION-T, 2GB, Satix S2 Dual, 1TB 2.5", yavdr 0.4
    Server: Intel DH67CF, Pentium G620, 8GB, 2x1000GB 2.5" Raid1, WLAN, Ubuntu 12.04 @22W
    TV: Panasonic P50G30

  • Zitat

    Originally posted by andreash
    Besteht denn irgendeine Chance, das an andere Chipsaetze anzupassen? Speziell der i830 der S100 waere dann ja praedestiniert fuer kleine Sat-Boxen mit gutem TV-Out (ueber VGA).


    sicher besteht die Moeglichkeit, das ganze an andere Chipsaetze anzupassen. Ich habe extra deswegen (bis auf die Erkennung der Fieldpolarity) nur Standard-VGA Register verwendet, die also auf jeder VGA existieren.


    Man muesste nur testen, ob die entsprechende VGA eine Aenderung des H_TOTAL_DISP Registers on-the-fly erlaubt (so wie die Radeons das tun). Das ist eigentlich der einzige Knackpunkt, den ich im Moment sehe.


    Leider kann ich mangels Zeit und Hardware diese Versuche nicht selbst machen. Kann aber gerne Hilfestellung dazu geben. Ich muss meine Entwicklung zunaechst ganz eng auf meine eigene Testumgebung also aktuell Radeon-Hardware und die xine-lib als Soft-Decoder begrenzen. Selbst da gibt es noch genug zu optimieren. Ich mache lieber 1 Sache 100% fertig als 5 Sachen halbfertig rumliegen zu lassen:)


    Mit der Version 'vga-sync-fields-0.0.6' von gestern und der aktuellen xine-lib aus dem HG laeuft jetzt auch Live-TV recht ordentlich. Reiner Wiedergabebetrieb macht schon seit laengerer Zeit keine besonderen Probleme mehr.


    bezueglich Live-TV:
    Mit der aktuellen HG xine-lib habe ich festgestellt, dass die ersten 10 Sekunden nach Kanalumschalten die Frames oft 5% zu schnell oder zu langsam kommen. Die scheinen hier auch noch irgendwas einzumessen.


    Damit hat meine Soft-PLL natuerlich noch Probleme, da diese selbstverstaendlich davon ausgeht, dass die Frames immer konstant ankommen. Sie weiss ja gar nichts davon, dass jemand den Kanal gewechselt hat.
    Die Folge ist, dass es nach Kanalumschalten z.T. 10 Sekunden dauert, bis die PLL wieder einrastet. Das Schlimmste was in diesem Fall passiert ist, dass man 10 Sekunden lang nach Kanalumschalten die Even- und Odd Fields vertauscht auf den Schirm bekommt. Hat man diese Phase jedoch ueberwunden wird man mit einem voellig ruckelfreien, artefaktfreien PAL Bild belohnt.


    Moeglicherweise muss man hier z.B. ein zusaetzliches Interface zwischen xine-lib und Xserver einziehen, damit sich die beiden fuer solche Spezialfaelle direkt unterhalten koennen. Das sind aber alles reine Software Probleme. Da kann jeder mitmachen. Feedback welcome! Darum haben wir ja Open-Source.


    Leider hat sich halt die letzten Jahre faelschlicherweise die Meinung etabliert, man koenne nur mit FF Karten ein wirklich gutes RGB Bild erzeugen. Nennenswerte Hardware-Entwicklungen an der FF vorbei hat es deswegen wohl kaum gegeben. Dass eine FF mit den erforderlich Mods dabei eine sehr aufwaendige und letztlich teure Loesung darstellt, die teilweise nicht mal Open-Source ist, scheint wenig zu interessieren. Leider muessen wir jetzt erst mal die Versaeumnisse der Vergangenheit aufholen.


    Aber die gute Aussicht eine FF Karte + Full TS Mod + proprietaere FW + Spannungs Mod + 4MB Mod + AV board durch eine 8EUR Radeon vom Grabbeltisch oder die OnBoard-Grafik einer S100 zu ersetzen, sind es vermutlich wert:)

  • Zitat

    Originally posted by sparkie
    bezueglich Live-TV:
    Mit der aktuellen HG xine-lib habe ich festgestellt, dass die ersten 10 Sekunden nach Kanalumschalten die Frames oft 5% zu schnell oder zu langsam kommen. Die scheinen hier auch noch irgendwas einzumessen.


    nein - ich habe hier noch weiter debugged - ist liegt gar nicht an xine-lib sondern am xineliboutput Plugin! :)


    Dieses hat einen versteckten Setup-Parameter:


    Code
    xineliboutput.Advanced.LiveModeSync = 0


    in der 'setup.conf'. Diesen kann man nur von Hand eintragen (ist also nicht ueber OSD zugaenglich). Der Parameter regelt den Pufferfuellgrad im Plugin bei Live-TV. Allerdings verursacht er starke Schwankungen (ueber 0.5%) der Ausgangsframerate.


    Diese Regelung muss in xineliboutput wesentlich feinfuehliger gemacht werden, was aber kein Problem ist. Das hat Petri sogar schon auf seiner ToDo Liste vermerkt.


    Wird dieser 'LiveModeSync' deaktiviert (er ist defaultmaessig an), habe ich jetzt fast Live-TV Umschaltzeiten, wie man sie von xineliboutput gewohnt ist. Sichtbare Nachteile den 'LiveModeSync' zu deaktivieren habe ich bis jetzt noch nicht mal festgestellt.


    Leute - wir kommen langsam an ein Produktivsystem ran! Mit einer simplen Radeon+billig Motherboard. Jetzt fehlt eigentlich nur noch WSS.


    shh hat in diesem Post schon mal eine Idee geaeussert:


    ATI radeon 9200se TV-Out


    Sonst noch jemand eine Idee wie das ueber eine VGA realisiert werden kann?

  • Hallo Sparkie,


    betrifft der Patch nun den i810 oder den i830? Denn die S100 hat m. E. den 830 verbaut.


    CU


    Opunkt

    Mein VDR: Silverstone LC 17 - Dual Core Celeron E3200 - 2 GB RAM - 1 TT 1501C mit Alphacrypt CAM 3.19 - 2 x 1 TB WD Green mit Videolibrary -60 GB SSD OCZ Vertex 2 mit yaVDR 0.3a - Nvidia 210 passiv - Logitech Harmony 515
    Mein TV: Panasonic TH-PV71F 42 Zoll Plasma über HDMI
    Mein Rechner: Apple iMac Core 2 Duo, 24 ", 2 GB Ram, 640 GB HD
    Mein Router: FritzBox!Fon 7270
    Mein Schatz: Barbara, 39 Jahre, blond, 52 kg

  • Zitat

    Original von sparkie
    Im Zuge der Portierung auf die S100 mit i810 anbei ein paar Vorab-Patches, die nun erstmalig den Betrieb von 720x576i mit der XV Extension des xserver-xorg-video-intel erlauben. Weitere Erlaeuterungen hier:


    i810 + xineliboutput: Nur halbes Bild zu sehen


    Hi sparkie,


    hoert sich praechtig an, dann werd ich meine SMT wohl mal reaktivieren (i810 chipsatz).


    Welche Distri bzw. welche sourcen von xserver-xorg-video-intel und xine verwendest du aktuell? Ich wuerd gern erstmal auf denselben versionen aufsetzen.


    merci,


    andreas

    VDR: ASUS AT3ION-T, 2GB, Satix S2 Dual, 1TB 2.5", yavdr 0.4
    Server: Intel DH67CF, Pentium G620, 8GB, 2x1000GB 2.5" Raid1, WLAN, Ubuntu 12.04 @22W
    TV: Panasonic P50G30

  • Hi,


    Zitat

    Originally posted by opunkt
    betrifft der Patch nun den i810 oder den i830? Denn die S100 hat m. E. den 830 verbaut.


    der Patch betrifft aktuell den i810. Fuer den gibt es gute Dokumentation. Aber der i830 scheint in vielen Dingen sehr aehnlich zu sein. Zumindest nach einem ersten Blick in die Sourcen.


    Zitat

    Originally posted by andreash
    hoert sich praechtig an, dann werd ich meine SMT wohl mal reaktivieren (i810 chipsatz).


    also ich muss zugeben ich habe mich weder mit S100 noch mit SMT im Detail beschaeftigt. Ich verwende zum
    Entwickeln einen ganz gewoehnlichen billig NEC-Desktop aus der Bucht.


    WIrd der Patch auf der SMT ueberhaupt was bringen? Die hat doch angeblich im Gegensatz zur S100
    gar keinen zugaenglichen VGA Port?


    Zitat

    Welche Distri bzw. welche sourcen von xserver-xorg-video-intel und xine verwendest du aktuell? Ich wuerd gern erstmal auf denselben versionen aufsetzen.


    ich hab das Entwicklungssytem mit Debian 5.0 und debootstrap aufgesetzt. Also keine VDR-Distri.
    Ich denke das ist aber nicht so entscheidend. Wichtig ist eigentlich nur:


    - linux-image-2.6.24-1
    - xserver-xorg-video-intel 2:2.3.2-2 or newer
    - xine-lib (1.1.16) or newer (HG)
    - xineliboutput (1.0.2) or newer (CVS)


    Die aktuellen Patches erlauben aber erst einmal nur den interlaced RGB/PAL-Output direkt am VGA-Port ueber Xserver + XV. Mit einem VGA2SCART Kabel kann man jetzt also SCART Geraete direkt betreiben. Was bislang ja nicht moeglich war.


    Es ist derzeit jedoch noch nicht moeglich eine variable Framerate (wie bei den Radeons) zu fahren. Daran arbeite ich noch. Es ist noch nicht sicher, ob die Intel Chips dies ueberhaupt zulassen!


    Deswegen ist bei Intel-Grafik derzeit noch der Einsatz eines Deinterlacers erforderlich.


    - sparkie

  • Die SMT hat keinen VGA-Port, das ist richtig.


    Sie hat allerdings mit dem Focus FS454 einen Chip, der von VGA nach Scart umsetzt. Vielleicht kann man den ja auch mit deinen Patches zur Mitarbeit bewegen. Das Kistchen ist ja manchmal nicht flott genug fuers deinterlacing.

    VDR: ASUS AT3ION-T, 2GB, Satix S2 Dual, 1TB 2.5", yavdr 0.4
    Server: Intel DH67CF, Pentium G620, 8GB, 2x1000GB 2.5" Raid1, WLAN, Ubuntu 12.04 @22W
    TV: Panasonic P50G30

  • Hallo Leute,


    die ersten Tests mit i810 und variabler Framerate sind durch! :alki


    Auch Intel scheint die Modifikation des HORIZ_TOTAL Registers im laufenden Betrieb zuzulassen.


    Damit ist der Grundstein fuer die Intel GMAs (und damit auch fuer die S100:)) wohl gelegt.


    Hier schon mal ein paar erste Bilder vom angeschlossenen Oszi (meinem alten HAMEG HM 204-2):




    [Blockierte Grafik: http://crashme.cx/vdr-portal-picts/IMG_5271ii.JPG]


    Bild 1. ohne Framerate-Korrektur (unten VSYNC, oben HSYNC), alle HSYNCs liegen gleich weit auseinander




    [Blockierte Grafik: http://crashme.cx/vdr-portal-picts/IMG_5268ii.JPG]


    Bild 2. mit Framerate-Korrektur (unten VSYNC, oben HSYNC), klar zu erkennen der verzoegerte 3. HSYNC.
    Die zugehoerige Scanline hat hier eine Laenge von 98.6usec statt der ueblichen 64usec.
    Die Verlaengerung geschieht im VBLANK-Interrupt des i810-DRM Modules.



    kleines Rechenbeispiel:


    Die eine 98,6usec Scanline im Field bewirkt eine Periodendauer von 20000usec + (98,6usec - 64usec) == 20034,6usec statt der ueblichen 20000usec pro Field.


    Wir haben also im Beispiel eine Fieldrate von nur 1 / 20034,6usec == 49,9136Hz statt der ueblichen 1 / 20000usec == 50Hz.



    - sparkie

  • Hallo zusammen,


    ich hab gerade mein VGA Kabel zerschnitten und dann festgestellt das am D-Sub Stecker der Pin 9 fehlt.
    Geht das ganze nur mit einem neuen Stecker oder kann ich diese Leitung auch irgendwie anders Realisieren?


    Ich hab schon mal hier gesucht aber keine Schaltung gefunden, welche ohne Pin 9 auskommt.


    Zur Not könnte ich vielleicht einen Pin reinstecken und anlöten.


    coke

    VDR:AMD Athlon X2 4850e, ASUS M3A-H/HDMI, 1 GB DDR2-RAM, 80 GB 3,5"HDD, Hauppauge DVB-C Rev. 2.1, Nova-T, Lorenzen DVB-T, Atric IR-Einschalter, easyvdr 0.6.2


    Server: Allnet ALL6250, 1xGb-LAN, 2xUSB, 400GB mit OPENNAS 1.7


    VDR-User #1475

  • Zitat

    Originally posted by coke
    ich hab gerade mein VGA Kabel zerschnitten und dann festgestellt das am D-Sub Stecker der Pin 9 fehlt.
    Geht das ganze nur mit einem neuen Stecker oder kann ich diese Leitung auch irgendwie anders Realisieren?


    du kannst die 5V+ natuerlich auch woanders herbeziehen.


    alles Wichtige zum Thema VGA2SCART Kabel habe ich


    schon mal hier gepostet


    sorry, die Infos muesste man mal irgendwie zusammenfassen:)

  • Hi,


    was wird denn passieren, wenn ich deinen Patch gegen xine-lib und den i810 chipsatz anwende, als Ausgabe aber nicht 25Hz VGA2Scart, sondern 50Hz 768x576 VGA nehme? Kann ich dann auch ohne deinterlacer auskommen?


    Ausprobieren ist etwas kompliziert, mein aktuelles setup ist mit directfb, ohne X. Wenn ich so aber ohne Deinterlacer auskommen koennte, waere es die Umstellung wert.


    Andreas

    VDR: ASUS AT3ION-T, 2GB, Satix S2 Dual, 1TB 2.5", yavdr 0.4
    Server: Intel DH67CF, Pentium G620, 8GB, 2x1000GB 2.5" Raid1, WLAN, Ubuntu 12.04 @22W
    TV: Panasonic P50G30

  • Nö. Wenn du die doppelten Informationen aus der Buchse spuckst musst du die auch liefern. Das ja genau der Grund warum es Deinterlacer gibt ;)

    - HTPC mit zerbasteltem Yavdr 0.6 , Origen ae X15e, MCE Remote, Asus P5N7A-VM, 1x Digibit R1, Kodi und vdr an Pana 46PZ85E
    - Diverse HTPCs im Umfeld bei Familie und Freundenm die sich vor mir fürchten, mit allen möglichen gruseligen Konfigurationen.
    Auch gern Debian, aber wehe jemand kommt mir mit Suse.

  • Zitat

    Original von Hibbelharry
    Nö. Wenn du die doppelten Informationen aus der Buchse spuckst musst du die auch liefern. Das ja genau der Grund warum es Deinterlacer gibt ;)


    Die dumme Frage kommt daher, weil ja xineliboutput bei 50Hz ausgabe ohne Deinterlacer ca. 20 sekunden lang perfektes bild liefert, dann die fields vertauscht, usw... Irgendwo verschwindet also immer mal wieder ein halbbild.


    So koennte man huebsch nen i810 per VGA an nen Plasma/LCD stoepseln. Und nebenher auch die SMT, wo die 50Hz per FS454 auf Scart umgesetzt werden.

    VDR: ASUS AT3ION-T, 2GB, Satix S2 Dual, 1TB 2.5", yavdr 0.4
    Server: Intel DH67CF, Pentium G620, 8GB, 2x1000GB 2.5" Raid1, WLAN, Ubuntu 12.04 @22W
    TV: Panasonic P50G30

  • Hallo,


    vorab erstmal vielen Dank an sparkie für die tolle Arbeit an diesem Thema hier!


    Mich interresiert insbesondere die Ausgabe per DVI bzw. HDMI an einen
    LCD TV über die Grafikkarte. Da ich noch eine ATI X1550 rumliegen hatte
    wollte ich den Patch natürlich sofort ausprobieren. Dummerweise hat die
    Karte einen RV515 womit der Patch leider nicht läuft.
    Also habe ich mich mal an die Treiberentwicklung gewagt und das Ergebnis möchte ich euch nicht vorenthalten. Herausgekommen ist bisher ein kpl. überarbeiteter Patch für den xf86-video-ati Radeon Treiber der eben auch Chips mit AVIVO Hardware
    unterstützt. Damit sollten jetzt auch prinzipiell alle R500 basierten ATI-Karten laufen. Meine X1550 tut es. :)


    Der Patch basiert auf dem xorg git-Stand vom 22.08.2008. Da am Radeon-Treiber heftig entwickelt wird sollte man erstmal genau diesen git Stand verwenden. Gepatched werden wie bei sparkies's Patch das DRM-Modul sowie der xorg-Treiber selber.
    Im Unterschied zu sparkie's Patch funktioniert die Regelung hier für beliebige Videomodes (z.b. 576i, 720p oder 1080i) und ist nicht auf PAL konforme Modes beschränkt.
    Somit kann man das ganze auch bei HDTV einsetzen was sicherlich für 1080i
    interresant ist da hier das deinterlacing die meisten Rechner zur Zeit noch überfordert.


    Um das Experimentieren zu erleichtern habe ich einige Parameter konfigurierbar gemacht. Diese sind als Option-Argumente in der Device-Section der xorg.conf konfigurierbar. Siehe hierzu die README-Datei aus der Anlage.
    Weiterhin erfolgt - ähnlich wie bei sparkie's Patch - die Ausgabe einiger statistischer Werte
    als Debugausgabe.


    Enthalten sind in diesem Patch auch die Patches zur Vermeidung von tearing bei der Ausgabe über Textured Video (was anderes gibt's zur Zeit nicht bei der AVIVO Hardware) sowie die Fixes bezüglich der interlaced Ausgabe bei den älteren Chip-Architekturen.


    Der Patch enthält bereits den notwendigen Code auch für die älteren Chip-Architekturen.
    Getestet ist von mir aber nur die AVIVO-Variante!!!! Vermutlich wird der Patch auf den
    älteren Chip-Architekturen so erstmal nicht einwandfrei laufen. Aber das müsste halt mal
    jemand ausprobieren.


    durchflieger


    Edit: Anhang ausgetauscht. Im xf86-video-ati.patch zwei C-Compiler warnings beseitigt

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!