[patch] RGB/PAL ueber VGA mit variabler Framerate

    andreash

    Zitat

    Originally posted by andreash
    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?


    Ohne Deinterlacer auszukommen kann nur funktionieren, wenn das Signal auch interlaced am Video-Port anliegt. In deinem Fall ist aber doch vermutlich eine progressive Modeline im Spiel? Darum kann es prinzipbedingt nicht funktionieren.


    Zitat

    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.


    du muesstest mal deine Konfiguration naeher beschreiben. Wenn Fields vertauscht werden, muessten die auch getrennt von deinem Ausgabegeraet interpretiert werden. Das widerspricht aber irgendwie deiner bisherigen Beschreibung.


    durchflieger

    Zitat

    Originally posted by durchflieger
    Mich interresiert insbesondere die Ausgabe per DVI bzw. HDMI an einen
    LCD TV über die Grafikkarte. Da ich noch eine ATI X1550 rumliegen hatte


    WOW! Das ist ja sensationell, was du da noch fuer zusaetzliche Features eingebaut hast!


    Deine Feature-List liest sich wie die Liste der unerledigten Punkte auf meinen ToDo-Notizen.


    Insbesondere fuer HDTV ist deine Variante sehr interessant. Schliesslich ist der Software-Deinterlacer auch bei H.264 der groesste CPU-Leistungs- und Qualitaetsvernichter im System.


    Der erste Schritt hin zum Graphikkarten-Support fuer HDTV unter Linux und weg von den proprietaeren FF-Karten?


    "beliebige Videomodes", insbesondere "1080i", neue "avivo-Hardware" und konfigurierbar ueber "xorg.conf", das alles hat meinem Patch bislang gefehlt. Klasse!


    Deine Arbeit waere eigentlich ein eigenes Announcement wert, meine ich. Nicht dass es hier untergeht:)


    Zitat

    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


    da ergaenzen wir uns ja gut. Mein Patch laeuft nur auf pre-avivo Hardware.


    Ich teste das gerne mal mit meinen alten Karten. Ich habe da inzwischen so einiges an Testhardware angesammelt. Sieht wohl so aus, als muesste ich mir auch noch schleunigst 'ne ATI X1550 besorgen.



    @all:
    heute habe ich mal wieder einen neuen Patch "vga-sync-fields-0.0.8.tgz" zusammengebaut. Sehr experimenteller Intel Support ist schon mal dabei. Siehe http://lowbyte.de/vga-sync-fields/


    - sparkie

    Hallo,

    Zitat

    Original von durchflieger
    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.


    Das klingt interessant.
    Ich verwende zwar nur SDTV, aber die Ausgabe ist 1080.


    Zitat


    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.


    Hm. Zur Zeit verwende ich den Treiber "radeon". Mein Xorg läuft auf 1920x1080. Momentan habe ich noch Probleme mit dem Deinterlacing.


    Sehe ich es richtig, dass ich wenn ich:
    1) die richtige Version des ati Treibers aus dem git herunterlade
    2) deinen patch anwende
    3) kompiliere
    4) in der xorg den ati statt den radeon verwende


    ich den deinterlacer in xine abschalten kann?


    Gruß,
    Hendrik

    Zitat

    Original von durchflieger
    Mich interresiert insbesondere die Ausgabe per DVI bzw. HDMI an einen
    LCD TV über die Grafikkarte.


    Hi durchflieger,


    das ist der Hammer! Wenn das stabil läuft schmeiss ich sofort meine Nvidia raus und schraube wieder eine Ati rein.


    Endlich ein geniales Bild per Hdmi :cool1

    SW: Ubuntu 10.04; yaVDR Pakete
    HW: Asus P5N7A-VM; 2x DVB-C rev2.1; Silverstone LC16B-M; Panasonic PT AX200e


    sparkie
    Danke für die Blumen! Für ein eigenes Announcement ist es mir eigentlich noch zu früh. Ich denke wir sollten erstmal testen ob mein Patch auch mit den älteren Chip-Generationen funktioniert. Wäre toll wenn du das mal ausprobieren könntest. Falls es nicht auf Anhieb klappt dann melde dich bitte. Ich kann dir dann zumindestens ein paar Tips geben woran es liegen könnte.
    Für die AVIVO-Hardware ist der Treiber momentan doch noch sehr problemtisch da erst in den letzten Wochen wichtige Funktionen hinzugekommen sind und der Treiber bei mir nur mit dem 1.5 xserver einigermassen funktioniert. In den letzten zwei Wochen sind schon wieder einige strukturelle Veränderungen im Treiber vorgenommen wurden so das der Patch wieder angepasst werden müsste.
    Deshalb ist es wahrscheinlich sinnvoller erstmal den Support für die älteren Chips ans laufen zu bekommen und den Patch dann für einen definierten Treiberstand (z.b. 6.9.0 tag) anzupassen.


    Gruss
    durchflieger

    Hallo zusammen,


    sparkie, durchflieger,


    also ich würde mich unwahrscheinlich freuen,


    wenn einer von euch beiden male eine kurze Anleitung schreiben würde, was man als


    - Ausgangsversion des X-Servers und Kernels braucht


    und


    - welche Patche man wo braucht?


    und


    welche Karten dafür geeignet sind?




    Evtl kann man das dann ja mal breiter testen und mithelfen.


    Danke schon mal für euere Arbeit.


    Gruß
    Wolfgang


    Hallo Hendrik,
    mein Patch ist für den Treiber "radeon" gedacht. Der Treiber ist ein Bestandteil des xf86-video-ati Packet das du dann als ganzes aus dem git auschecken musst. Weiterhin benötigst du mindestens noch das mesa/drm Packet in dem sich das DRM-Modul "radeon" befindet. Falls du auf AVIVO-Hardware testen willst empfehle ich dir den ganzen xorg Stack zu übersetzen da der Treiber wohl nur mit dem xserver 1.5 vernüftig funktioniert.


    Wenn du extern deinterlacen willst (mittels deinem TV) dann solltest du genau in der Auflösung ausgeben in dem das Quellmaterial vorliegt. Bei PAL SDTV also mit 720x576@50i. Es darf kein Scaling im Player stattfinden. Nur so wird das externe deinterlacing eine gute Bildqualität ergeben.


    Gruss
    durchflieger


    Hallo KleinKlausi,
    behalte deine Nvidia lieber erstmal! Zumindestens in meinem Testsystem ist die aktuelle Bildqualität der Videoausgabe über die X1550 doch sehr bescheiden! Das liegt aber nicht an den hier vorgestellten Patches sondern vermutlich (oder besser hoffentlich) wohl an dem noch nicht ausgereiften Radeon-Treiber. Meine nvidia Geforce 8300 OnBoard Graphik macht da zur Zeit bei 720p einfach ein viel besseres Bild.


    Gruss
    durchflieger

    durchflieger:

    Zitat

    Originally posted by durchflieger
    Ich denke wir sollten erstmal testen ob mein Patch auch mit den älteren Chip-Generationen funktioniert. Wäre toll wenn du das mal ausprobieren könntest. Falls es nicht auf Anhieb klappt dann melde dich bitte. Ich kann dir dann zumindestens ein paar Tips geben woran es liegen könnte.


    ja, das mache ich gerne. Dann wuerde ich einfach mal mein gesamtes Radeon Sammelsurium testen.


    Eine MSI RX1550-TD128EH ist deswegen auch schon im Anflug - kostet ja nur 14EUR:)


    Zitat

    und der Treiber bei mir nur mit dem 1.5 xserver einigermassen funktioniert.


    womit wir zu Wolfgang kommen:


    wolfgang:

    Zitat

    Originally posted by wbreu
    wenn einer von euch beiden male eine kurze Anleitung schreiben würde, was man als
    - Ausgangsversion des X-Servers und Kernels braucht


    Zitat

    welche Karten dafür geeignet sind?


    beides steht ja im Falle des vga-sync-fields Patches (hoffentlich genug) detailliert im zugehoerigen README. Ich muss aber zugeben, dass sich mein Referenzsystem im Laufe der Zeit immer mehr vom Sourcestand der aktuellen Debian 5.0 entfernt hat. Ich wuerde deine Frage genau umgekehrt formulieren:


    Welche Ausgangsbasis *sollten* wir in Zukunft nehmen?


    im Falle des vga-sync-fields Patches habe ich ausser zur xine-lib und dem xineliboutput-Plugin uebrigens keine besonderen Anforderungen an die Aktualitaet des
    Systems. Die Funktionalitaet von Debian 4.0 ist fuer vga-sync-fields bereits ausreichend. Wenn auch der Patch dafuer noch angepasst werden muesste.


    Vorschlag: wir rebasieren auf aktuelles Debian 5.0 - nur in Ausnahmefaellen (wenn Sourcen nicht vorhanden oder zu alt) weichen wir auf aktuellere Repositories aus.
    Welchen Kernel sollen wir hierzu nehmen? Evt. kann man gleich das dort vorhandene DRM-Modul als Grundlage verwenden (statt das DRM aus dem mesa/drm Packet)


    - sparkie

    Zitat

    Original von sparkie
    ...
    Vorschlag: wir rebasieren auf aktuelles Debian 5.0 - nur in Ausnahmefaellen (wenn Sourcen nicht vorhanden oder zu alt) weichen wir auf aktuellere Repositories aus.
    Welchen Kernel sollen wir hierzu nehmen? Evt. kann man gleich das dort vorhandene DRM-Modul als Grundlage verwenden (statt das DRM aus dem mesa/drm Packet)


    - sparkie


    Ok. Ich installiere mir hier mal ein Debian 5.0 in einer VM und schaue es mir mal an. Mein Testsytem (und leider auch Produktivsystem) basiert auf Ubuntu/Gutsy. Das kann ich leider nicht so einfach austauschen. Ich denke aber das man unter der VM die Patches anpassen kann und zumindestens rudimentär testen kann. Im Bauen von Debian-Paketen habe ich auch schon einige Erfahrung.


    Gruss durchflieger

    also wenn ich auf Debian 5.0 eingebe:


    Code
    apt-get -t unstable source xserver-xorg-video-ati
cd xserver-xorg-video-ati-6.9.0
patch -p0 < /root/xf86-video-ati.patch
dpkg-buildpackage


    dann laeuft der Patch ohne Rejects durch. Binaries werden alle gebaut. Evtl. brauchen wir doch nicht die allerneuesten Sourcen? Die schrauben derzeit wohl hauptsaechlich in den 'RV770_*' Chipsets herum.


    ansonsten


    Code
    git-clone git://anongit.freedesktop.org/git/mesa/drm
cd drm/linux-core
patch -l < /root/radeon_drm.patch


    gibt einen Reject, den man aber leicht von Hand aufloesen kann. Das ergibt ein System, welches bei mir zumindest auf der alten IGP9100 Hardware schon mal ein Xserver- Rootwindow zeigt.


    XV Betrieb: schaue ich mal ob ich heute noch dazu komme...


    Die RX1550 wird vermutlich erst Donnerstag geliefert. Eigentlich macht die Testerei erst Sinn wenn ich Avivo und Non-Avivo Hardware parallel testen kann.

    sparkie


    Das xserver-xorg-video-ati Packet aus unstable scheint eine Komposition der debian Maintainer zu sein. Es enthält Patches aus dem xorg git bis Anfang September entspricht aber nicht dem git Stand.
    Der xorg xserver ist in unstable die Version 1.4.2.


    Ich bin zur Zeit mit "experimental" unterwegs da hier bereits xorg xserver 1.5 da ist
    und das xserver-xorg-video-ati ist eine Kopie des git-Stand von Anfang September. Das kommt meiner aktuellen Testumgebung einfach näher so dass ich die
    Debian 5.0 Packete auch in meiner Testumgebung compilieren und testen kann.


    Ich hoffe dass ich morgen die angepassten Patches online stellen kann.


    Für Hardware vor AVIVO dürfte der Stand aus unstable aktuell genug sein. Wenn die
    Patches so durchlaufen dann versucht es einfach mal. Nur kann ich hier diesen Stand
    selber schlecht testen.


    Da der xserver vor 5 Tagen bereits auf V1.5 getagged wurde und damit seitens xorg wohl
    jetzt eine offizielle Version sein dürfte denke ich sollten wir uns schon auf diese Version fixieren.


    Ich bin bisher bei meiner Debian V5 Installation folgendermasssen vorgegangen:


    apt-get -t experimental install xorg-xserver
    apt-get -t experimental source xorg-xserver-video-ati


    Der aktuelle Debian Linux-Kernel 2.6.26 enthält einen
    recht alten Stand des DRM wo ich von AVIVIO nicht viel erkennen kann.
    Da werden wir wohl erstmal tatsächlich auf dem xorg git aufsetzen müssen. Kann
    man mit dem git Kommando eigentlich einen Snapshot anhand eines Datum ziehen?


    Ich bin sehr gespannt auf deine Tests insbesondere ob die ältere Hardware eine
    bessere Bildqualität hat als die AVIVO Hardware. Wenn dass so ist dann werde
    ich mir auch noch eine ältere Karte ersteigern.


    Gruss
    durchflieger

    durchflieger:

    Zitat

    Da der xserver vor 5 Tagen bereits auf V1.5 getagged wurde und damit seitens xorg wohl
    jetzt eine offizielle Version sein dürfte denke ich sollten wir uns schon auf diese Version fixieren.


    alles klar. Ich stelle dies bei mir entsprechend um und werde in Zukunft die vga-sync-fields Patches auf dieser Basis erstellen.
    Irgendwann sollte es dann sowieso nur noch *einen* Patch (Merge aus deinem und meinem) geben.


    Zitat

    Ich bin sehr gespannt auf deine Tests insbesondere ob die ältere Hardware eine
    bessere Bildqualität hat als die AVIVO Hardware. Wenn dass so ist dann werde
    ich mir auch noch eine ältere Karte ersteigern.


    Bezueglich Bildqualitaet kann ich nur sagen: die ist fuer pre-AVIVO Hardware hervorragend. Eventuell handeln wir uns da mit
    der X1550 unnoetig Probleme ein. Ausserdem kosten die alten pre-AVIVOs in der Bucht nur ein paar Euro.


    Ich werde die Tests beginnen, sobald die RX1550 da ist. Damit ich Fixes immer gleich gegentesten kann.


    Also ich faende es gut, wenn wir mal eine Uebersicht der aktuell funktionsfaehigen und geplanten Hardware zusammenstellen koennten.
    Der Grund, warum du auf die X1550 gegangen bist war doch eigentlich nur der, weil diese bei dir noch herumlag?


    Es gibt aus meiner Sicht eigentlich keinen Grund ausgerechnet diese Karte zu unterstuetzen und sich deswegen die AVIVO-Probleme
    einzuhandeln. Die DVI-I Schnittstelle, um die es dir ja eigentlich geht wird auch von pre-AVIVO Hardware unterstuetzt.
    Und diese alte Hardware laeuft stabil und die Video-Ausgabe ist von sehr guter Qualitaet.


    Ich finde auf die neuesten Radeon Sourcen umzusteigen macht erst richtig Sinn fuer den Support von HDMI.
    Z.B. die Sapphire HD3450 waere da recht interessant dafuer. Kostet derzeit nur ca. 24EUR. Eigentlich sollten wir zum Test deiner neuesten Patches gleich
    auf diese Karte umsteigen? Was haeltst du davon?


    Dann wuerden wir gleich alle Schnittstellen SCART/ VGA/ DVI-I/ HDMI unterstuetzen. Hier eine Uebersicht geordnet nach Schnittstellen:


    SCART/ VGA:
    - unterstuetzt fuer 576i50 von vga-sync-fields Patch (stable)
    - unterstuetzt fuer weitere SD-Aufloesungen von durchflieger Patch (experimental)
    - Beispielhardware:

    • Radeon 7000 (AGP) - RV100 (pre-AVIVO)
    • Radeon 9200SE (AGP) - RV280 (pre-AVIVO)


    SCART/ VGA/ DVI-I:
    - unterstuetzt fuer 576i50 von vga-sync-fields Patch (stable)
    - unterstuetzt fuer weitere SD-Aufloesungen und HDTV von durchflieger Patch (experimental)
    - Beispielhardware:

    • Gigabyte 9250 (AGP) - RV280 (pre-AVIVO)
    • Sapphire 9600SE (AGP) - RV350 (pre-AVIVO)
    • Sapphire X300SE (PCIe) - RV370 (pre-AVIVO)
    • MSI RX1550-TD128EH (PCIe) - RV515 (AVIVO) (nur durchflieger Patch)


    HDMI:
    - unterstuetzt fuer SD-Aufloesungen und HDTV von durchflieger Patch (experimental)
    - Beispielhardware:

    • Sapphire HD3450 HDMI (PCIe) - RV620/RV635

    Hi ihr!


    Das hört sich ja wirklich alles super an... Aber eine Frage habe ich noch.


    Kann man bei den pre-AVIVO den TV-Out parallel als framebuffer nutzen? Ich habe da ein TFT mit touch dran.


    Und zur Leistung: Komme ich mit einen Celeron 900Mhz hin?


    Volker

    VDR1: POV ION 330 mit Media-Pointer MP-S2 auf yaVDR 0.3.1 - enermay 370 Watt - 80GB SSD + 500GB HD - CoolerMaster ATX-620 - VGA2Scart + HDMI
    VDR2: Zotak ZBOX ID40 auf yaVDR unstable - Sundtek DVB-S2 + remote Sundtek - 60GB SSD - HDMI
    VDR3    : Zotak ZBOX ID40 auf yaVDR unstable - remote Sundtek - 500GB HD - DVI
    Atom 2700 mit 13W, Ubuntu PP, 60GB SDD + 240GB SSD, 2x Sundtek DVB-S2

    Über die Leistung brauchst du dir eher weniger Sorgen machen als vorher. Das mit den Ausgängen ist aber nicht drin. Auf einem Head X laufen lassen und nem anderen n einfachen Framebuffer kann soweit ich weiss eigentlich kein Treiber. Vielleicht wärs aber hinzubekommen immerhin nen getrennten X Bildschirm mit eigenem Inhalt auf die zweite Buchse zu bekommen.


    Grüz
    Hibbelharry

    - 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.

    sparkie


    Hier noch mal ein überarbeiteter Stand meiner Patches. Im DRM-Patch habe ich noch Fehler im Code für pre-AVIVO Hardware gefunden. Bitte führe deine Tests möglichst mit diesem Stand durch.


    Die Patches basieren jetzt auf Debian V5.0. In der README-Datei habe ich mal ein paar Build-Instructions ergänzt. Diese erheben aber noch keinen Anspruch auf Vollständigkeit!


    Bisher konnte ich noch keine Tests durchführen. Garantiert ist nur das alles compiliert.


    Ich werde heute mal meine Debian V5 Installation auf einen Notebook mit ATI HD2400 Onboard Graphik installieren und damit mal Tests machen. Allerdings ist da ja bereits ein R600 drin und ich glaube noch nicht so recht ob das mit dem radeon-Treiber gehen wird.


    Gruss
    durchflieger

    Zitat

    Original von Hibbelharry
    Über die Leistung brauchst du dir eher weniger Sorgen machen als vorher. Das mit den Ausgängen ist aber nicht drin. Auf einem Head X laufen lassen und nem anderen n einfachen Framebuffer kann soweit ich weiss eigentlich kein Treiber. Vielleicht wärs aber hinzubekommen immerhin nen getrennten X Bildschirm mit eigenem Inhalt auf die zweite Buchse zu bekommen.


    Grüz
    Hibbelharry


    Support für den zweiten Head ist in meinem Patch enthalten. Getestet habe ich das bisher noch nicht.

    Zitat

    Originally posted by v_r
    Kann man bei den pre-AVIVO den TV-Out parallel als framebuffer nutzen? Ich habe da ein TFT mit touch dran.


    das habe ich noch nie probiert - kann ich leider nichts zu sagen


    Zitat

    Und zur Leistung: Komme ich mit einen Celeron 900Mhz hin?


    da sehe ich keine Probleme. Allenfalls wenn eine aufwendige Variante eines OSD im Spiel ist.
    Ob die Leistung reicht kann man immer leicht selbst vorab testen, indem man den Software-Deinterlacer
    voruebergehend komplett abschaltet. Dann hast du genau die CPU-Belastung, wenn der Patch aktiv ist.
    Dabei zum Testen am besten einen Spielfilm hernehmen, da dieser meist von Haus aus progressiv
    vorliegen duerfte.


    Zitat

    Originally posted by durchflieger
    Hier noch mal ein überarbeiteter Stand meiner Patches. Im DRM-Patch habe ich noch Fehler im Code für pre-AVIVO Hardware gefunden. Bitte führe deine Tests möglichst mit diesem Stand durch.


    super, vielen Dank fuer die Patches! Ich wuerde am liebsten erst mit der RX1550 beginnen. Das ist ja genau deine Grundlage. Wenn das funkt, gehe ich auf meine pre-AVIVO Hardware. Meine RX1550 kommt vmtl. aber erst am Freitag...

    Zitat

    Original von durchflieger
    mein Patch ist für den Treiber "radeon" gedacht. Der Treiber ist ein Bestandteil des xf86-video-ati Packet


    Ah, ok. Daher die Verwirrung radeon <-> ati.


    [/quote]
    Wenn du extern deinterlacen willst (mittels deinem TV) dann solltest du genau in der Auflösung ausgeben in dem das Quellmaterial vorliegt. Bei PAL SDTV also mit 720x576@50i. Es darf kein Scaling im Player stattfinden. Nur so wird das externe deinterlacing eine gute Bildqualität ergeben.
    [/quote]


    Das bedeutet auch, dass der schwarze trauerrand nicht weggezoomt werden darf, oder?


    Davon abgesehen wäre es ok, die Auflösung auf PAL runter zu drehen und den TV Skalieren zu lassen. Leider würde ich dann wohl das schöne HD-OSD verlieren...


    Gruß,
    Hendrik

    Zitat

    Original von henfri
    ...
    Das bedeutet auch, dass der schwarze trauerrand nicht weggezoomt werden darf, oder?


    Davon abgesehen wäre es ok, die Auflösung auf PAL runter zu drehen und den TV Skalieren zu lassen. Leider würde ich dann wohl das schöne HD-OSD verlieren...


    Normalerweise sollte dein TV in die Betriebsart "tv" wechseln wenn eine standard Videoauflösung ausgegeben wird. Die drei Modelines in der
    README-Datei meines Patches sind solche standard Auflösungen. Der TV skaliert dann mit Overscan so das keine Trauerränder entstehen. Bei neueren LCD-TV's lässt sich dieses Verhalten sogar konfigurieren.


    Das schöne HD-OSD ist dann leider erstmal weg. Zumindestens für die HDTV Auflösungen sollte sich aber ein HD-OSD machen lassen. Ich habe hier bei mir schon ein modifiziertes xineliboutput am laufen das dynamisch den Mode per xrandr passend zum DVB-Stream umschaltet. Getestet habe ich das aber bisher ohne HD-OSD. Das wäre dann wohl die nächste Baustelle.


    Überigens darf die Scalierung im xineliboutput nicht radikal abgeschaltet werden. Programme wie das "Vierte Programm" senden z.B. in 480x576. Hier muss dann schon noch auf 720x576 skaliert werden.


    Gruss
    durchflieger

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden