[patches} Korrekte interlaced und framesynchrone Ausgabe für SDTV/HDTV auf VGA/DVI/HDMI/RGB/SCART

    Hallo Matthias,


    Zitat

    Original von Hitman47
    Mir kam nun aber in den Sinn, dass man dieses Problem vielleicht kompensieren kann. Vielleicht könnt
    ihr dazu etwas erzählen, denn konkretisieren konnte ich bisher noch nichts :)


    Erhöhe mal den Wert des Parameter "FrameRateTrimInterval" z.b. auf 10. Damit wird der Drift über mehr Frames gemittelt was evt. zu einer besseren (aber trägeren) Regelung führen könnte.


    Bezüglich der feinen Kammeffekte könnte es sich evt. um ein Problem des scalers in vertikaler Richtung handeln. Deine GraKa bietet ja textured wie auch overlay XV-Adapter an. Du solltest mal im xine setup beide Adapter ausprobieren. Beim overlay Adapter gibt es da wohl ein Problem dass durch einen Patch von sparkie behoben werden konnte. Der textured adapter hatte das Problem wohl nicht.


    Gruss
    durchflieger

    Hallo Hitman47


    Zitat

    Originally posted by Hitman47
    Meine Beobachtungen dazu auf meinem System (Pundit-R) möchte ich gerne schildern.


    danke fuer deinen umfangreichen Testbericht!
    wie du ja von unseren frueheren Tests weisst, habe ich unter anderem genau denselben Barebone.


    Zitat

    Als Basissystem verwende ich eine archlinux-Installation (Kernel-2.6.28-ARCH). Die


    bei mir laeuft hingegen debian lenny als Basis


    Zitat

    Es wird tatsächlich auch geregelt. Das lässt sich in der Xorg.log beobachten, die ich
    auch an den Post anhängen werde. In dieser Logdatei ist aber auch sichtbar, dass die
    Zyklen unregelmäßig sind; erkennbar an den Timestamps.
    Diese Unregelmäßigkeit wird wohl durch die massigen Interrupts auf meinem System verursacht.


    diese Unregelmäßigkeiten kann ich auf meinem System mit identischer Hardware aber anderer Software nicht nachvollziehen.
    Es waere in deinem Fall aber erst mal wichtig zu wissen, an welcher Stelle die Unregelmäßigkeit entsteht.


    Ich hatte mit aelteren xineliboutput/xine-lib Kombinationen schon die tollsten Effekte. Ich weiss
    nicht, was du im Moment verwendest.


    Deswegen habe ich zum Debug des xine-lib Timings einen kleinen Patch geschrieben (siehe Anhang).
    Wenn hier schon Unregelmäßigkeiten zu beobachten sind ist klar, dass das Gesamtsystem nicht funktionieren kann.


    ich habe frueher xine-lib-Debug und Xorg.0.log immer nebeneinander gelegt (beide geben genau eine Zeile pro Sekunde aus).
    Dann kann man anhand der ausgegebenen Timingwerte genau sehen, was Sache ist.


    Nach Start einer Wiedergabe (siehe charakteristischer Einschwingvorgang) sieht es typisch so aus:
    xine-lib-Debug (mit Patch im Anhang) meines pundit ID-3:


    zeitgleicher Xorg.o.log Output:


    Wichtig ist erst mal nur jeweils die rechte Spalte. Das ist die Zeit, die die letzten 50 Fields in Anspruch genommen haben. Idealwert ist 1000000usec == 50 * 20000usec.


    avanix:
    Hitman47:
    Es waere interessant, was eure Systeme hier fuer Werte liefern!


    Zitat

    Mir kam nun aber in den Sinn, dass man dieses Problem vielleicht kompensieren kann. Vielleicht könnt
    ihr dazu etwas erzählen, denn konkretisieren konnte ich bisher noch nichts :)


    wie gesagt ich wuerde erst mit dem angehaengten Patch checken, ob die Frames aus xine regelmaessig kommen.
    Hier wuerde man auch sofort sehen, ob Probleme mit dem speziellen Timing, das xineliboutput fuer Live-Wiedergabe verwendet, vorhanden sind.


    BTW:
    Ich bin mittlerweile zu dem Schluss gekommen, dass es nur Sinn macht die FRC Patches
    im Rahmen einer VDR-Komplett-Distribution anzubieten. Da das gesamte System miteinbezogen wird,
    muss alles genau zusammenpassen.


    Genauso wie es mit FRC fuer Intel i9xx chips auf easy-vdr inzwischen erfolgreich begonnen wurde.


    - sparkie

    Hi,


    ich verwende im Moment die xine-lib 1.1.16.1 mit dem Patch, der usleep() bevorzugt und vdr-xineliboutput 1.0.4 mit der config_xineliboutput von sparkie.
    Den "preferred" Adapter habe ich auf textured Video umgestellt. Dabei zappelt das Bild nun allerdings die ganze Zeit über, so dass beispielsweise die Nachrichtenticker permanent verschwimmen.


    Im Anhang sind die Logdaten. Falls mehr oder noch andere Daten benötigt werden, will ich die gerne zur Verfügung stellen.


    So long.

    Hallo Hitman47


    Zitat

    Originally posted by Hitman47
    Den "preferred" Adapter habe ich auf textured Video umgestellt. Dabei zappelt das Bild nun allerdings die ganze Zeit über, so dass beispielsweise die Nachrichtenticker permanent verschwimmen.


    fuer die alten pre-avivos (also auch den Pundit) ausschliesslich overlay statt textures verwenden. Sonst kann es nicht gehen.


    [edit]Config-Files wie hier beschrieben, falls du durchfliegers Patches verwendest[/edit].


    - sparkie

    Hallo Hitman47,


    Zitat

    Originally posted by Hitman47
    Im Anhang sind die Logdaten. Falls mehr oder noch andere Daten benötigt werden, will ich die gerne zur Verfügung stellen.


    gerade habe ich noch deine xine-lib-Debug.log.gz durchgesehen.
    Ausschnitt:


    diese Werte muessen zwangslaeufig zu Sync Problemen fuehren. Hier werden im Schnitt deutlich ueber 5ms pro 50 Fields zu viel benoetigt. Da kann irgendwas grundsaetzlich (auf xine-lib oder xineliboutput) Seite schon nicht stimmen. Das hat mit dem Xserver noch gar nichts zu tun.
    EIn Gut-Beispiel, wie es aussehen muesste siehe meinen Post oben.


    Hast du hier schon den xineliboutput Patch fuer den live-Mode aktiv?


    - sparkie

    Hallo sparkie,


    Zitat

    Originally posted by sparkie
    Hast du hier schon den xineliboutput Patch fuer den live-Mode aktiv?


    Ich weiß nicht genau, was du meinst. Einen Patch speziell für vdr-xineliboutput habe ich noch nicht gesehen. Ich habe daher im Forum etwas gesucht und bin auf die Zeilen


    Code
    xineliboutput.Advanced.LiveModeSync = 0
input.xvdr.scr_tuning_step:200


    gestoßen.
    Ich hatte die Optionen noch in Erinnerung, wohl aber nie zusammen verwendet. Nun scheint es so zu funktionieren, wie es soll.
    Ich hänge die Logs an. Genauere Tests mache ich bei Gelegenheit. Speziell dieser ganz feine Kammeffekt und Mikroruckler.


    So long und vielen Dank für die Unterstützung.

    Hallo Hitman47


    Zitat

    Originally posted by Hitman47
    Ich weiß nicht genau, was du meinst. Einen Patch speziell für vdr-xineliboutput habe ich noch nicht gesehen. Ich habe daher im Forum etwas gesucht und bin auf die Zeilen


    Code
    xineliboutput.Advanced.LiveModeSync = 0
input.xvdr.scr_tuning_step:200


    sehr gut, das ist genau die Stelle, die ich meine! Diesen Hinweis muesste durchflieger unbedingt noch
    in sein README mitaufnehmen. Ohne diese Konfiguration kann es nicht gehen.
    Eine noch bessere Loesung als den LiveModeSync auf Null zu setzen ist aber ein spezieller Patch,
    den durchflieger in einem anderen Zusammenhang hier schon mal veroeffentlich hat (siehe auch Anhang).


    Zitat

    Nun scheint es so zu funktionieren, wie es soll.
    Ich hänge die Logs an. Genauere Tests mache ich bei Gelegenheit. Speziell dieser ganz feine Kammeffekt und Mikroruckler.


    beide Logs sehen jetzt sehr gut aus! Was fuer ein Unterschied zu deinem vorigen Log! Das hat's also wirklich gebracht.:tup
    siehe im Vergleich auch meine eigenen Logs von diesem Post


    avanix:
    mit dem Hinweis von oben sollte es bei dir auch funktionieren (du muesstest denselben Softwarestand wie Hitman47 haben)


    durchflieger:
    der Hinweis mit dem 'LiveModeSync' muesste unbedingt noch ins README mit aufgenommen werden. Besser waere aber noch ein Hinweis auf deinen eigenen Patch (siehe Anhang) bzgl. 'input.xvdr.scr_tuning_step'.


    Damit haben wir vermutlich die Ursache gefunden, warum es bei manchen Leuten hier noch Probleme gibt.


    - sparkie

    Zitat

    Original von sparkie
    durchflieger:
    der Hinweis mit dem 'LiveModeSync' muesste unbedingt noch ins README mit aufgenommen werden. Besser waere aber noch ein Hinweis auf deinen eigenen Patch (siehe Anhang) bzgl. 'input.xvdr.scr_tuning_step'.
    - sparkie


    Im ersten Artikel dieses Thread steht nun neue download version 0.9.1 mit erweitertem README zur Verfügung.


    Gruss durchflieger

    ok, werde heute abend oder morgen mal testen.
    Ich füge dann nur diese Zeile "xineliboutput.Advanced.LiveModeSync = 0" in die vdr setup.conf ein.
    Für die andere Zeile bräuchte ich einen Patch?

    VDR: Mainboard: MSI B85M-G43; CPU: Pentium G3250 (Haswell); NVIDIA GT630 (GK208 Kepler); SanDisk SSD 64GB SDSSDP-064G-G25 + 500 GB HD; TV: DD Cine CT V6 - Twin Tuner Karte DVB-C (PCI Express Karte); atric USB eco Einschalter


    Hi Sparkie
    Ich muss nochmal nerven. Im EasyVDR-Portal hatte ich neulich die Frage gestellt, ob man deine FRC-Patches für Intel 9xx auch mit EasyVDR + vdr1.6 ans laufen bekommt (du erinnerst dich, da gibts ein Skript von Prudentis mit dem man den EasyVDR von vdr1.4.7 auf vdr1.6 umstellen kann indem ein paar Softlinks verbogen werden).
    Kannst du, wenn du Zeit und Lust hast, in dem Thread http://www.easy-vdr.de/forum/index.php?topic=6563.0 etwas dazu schreiben?
    Würde gerne den vdr1.6 wegen des neueren music-Plugins mit deinen Patches benutzen. Dann könnte mein Test-VDR so langsam die Ablöse meines Wohnzimmer-VDR übernehmen. Vga2scart+FRC+EasyVDR(vdr1.4.7) funktioniert soweit mit Hardware-OSD zu meiner Zufriedenheit wenn ich nur Fernsehe oder Aufnahmen schaue. Fürs Musikhören mit dem aktuellen Music-Plugin reichts noch nicht, dafür brauch ich EasyVDR mit vdr1.6. :prost2


    Gruß
    Jarny

    MLD 3.0.3 Server. Aufnahmen schaue ich mit einem separaten XBMC (OpenElec Distribution) im Wohnzimmer am 47 Zoll HD Fernseher

    also ich habe eben das system mal neu aufgesetzt mit Ubuntu 8.10, weil sich da die FRC Patches schon mal problemlos installieren und benutzen (mit Flimmern) ließen.


    Die FRC lässt sich in Mode 4 nicht starten:
    Wenn die Wiedergabe beginnen sollte kommt:

    Code
    (EE) RADEON(0): [drm] setting frame rate trim value failed! Frame rate control disabled


    Mode 1 funktioniert. Die Regelung wirkt hier mit dem neuen Parameter für xineliboutput viel stabiler:

    Die Striche bleiben an einer Postition stehen und springen nicht mehr wie bisher wild umher.
    Sie stehen allerdings bei unterschiedlichen Aufrufen nicht immer an der selben Stelle. Um Perfekt zu sein, müssten die wohl bei dem + sein?


    Kann mir jemand sagen, warum Mode 4 nicht geht (das ging nämlich schon mal)?
    Ich habe das Gefühl ich bin soooo nah dran, wenn jetzt noch Mode 4 läuft, dann könnte es alles klappen wie gedacht.


    Anbei ein Xorg.0.log wo das FrameRateControl "4" scheitert.

    Dateien

    Xorg0.txt 36,42 kB – 170 Downloads

    VDR: Mainboard: MSI B85M-G43; CPU: Pentium G3250 (Haswell); NVIDIA GT630 (GK208 Kepler); SanDisk SSD 64GB SDSSDP-064G-G25 + 500 GB HD; TV: DD Cine CT V6 - Twin Tuner Karte DVB-C (PCI Express Karte); atric USB eco Einschalter

    2 Mal editiert, zuletzt von avanix ()

    Hi


    Zitat

    Original von avanix
    Die FRC lässt sich in Mode 4 nicht starten:
    Wenn die Wiedergabe beginnen sollte kommt:

    Code
    (EE) RADEON(0): [drm] setting frame rate trim value failed! Frame rate control disabled


    Hast du folgendes aus der README des FRC-Patches genau befolgt?; zur Not kannst du das System mal neu starten.




    So long.

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2; DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

    Zitat

    Original von Hitman47
    Hast du folgendes aus der README des FRC-Patches genau befolgt?; zur Not kannst du das System mal neu starten.



    bin exakt so vorgegangen, habs zweimal gemacht, beim zweiten mal sogar mit komplett frischem system...
    Der Mode 4 hat ja bei mir schon mal funktioniert.... an dem neuen Parameter liegts auch nicht, wenn ich den rausnehme, dann geht's auch nicht... *Verzweiflung*

    VDR: Mainboard: MSI B85M-G43; CPU: Pentium G3250 (Haswell); NVIDIA GT630 (GK208 Kepler); SanDisk SSD 64GB SDSSDP-064G-G25 + 500 GB HD; TV: DD Cine CT V6 - Twin Tuner Karte DVB-C (PCI Express Karte); atric USB eco Einschalter

    Hi,


    Ich hatte mal ein Problem mit gleicher Fehlermeldung. Dabei habe ich vergessen den Patch auf die libdrm-Quellen anzuwenden und die Kernelmodule kompiliert und installiert. Das ergab dasselbe Problem wie bei dir.
    Prüfe doch einmal, ob folgender Befehl etwas ausgibt (aus dem Unterordner linux-core aufgerufen):

    Code
    grep -r DRM_IOCTL_RADEON_FRAME_RATE_CONTROL .


    So long.

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2; DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

    2 Mal editiert, zuletzt von Hitman47 ()

    Code
    avanix@vdr:~/libdrm-2.4.3/linux-core$ grep -r DRM_IOCTL_RADEON_FRAME_RATE_CONTROL .
./radeon_drm.h:#define DRM_IOCTL_RADEON_FRAME_RATE_CONTROL      DRM_IOWR(DRM_COMMAND_BASE + DRM_RADEON_FRAME_RATE_CONTROL, drm_radeon_frame_rate_control_t)


    ich glaube der patch ist da, oder?

    VDR: Mainboard: MSI B85M-G43; CPU: Pentium G3250 (Haswell); NVIDIA GT630 (GK208 Kepler); SanDisk SSD 64GB SDSSDP-064G-G25 + 500 GB HD; TV: DD Cine CT V6 - Twin Tuner Karte DVB-C (PCI Express Karte); atric USB eco Einschalter

    Einmal editiert, zuletzt von avanix ()

    Zitat

    Original von avanix

    Code
    avanix@vdr:~/libdrm-2.4.3/linux-core$ grep -r DRM_IOCTL_RADEON_FRAME_RATE_CONTROL .
./radeon_drm.h:#define DRM_IOCTL_RADEON_FRAME_RATE_CONTROL      DRM_IOWR(DRM_COMMAND_BASE + DRM_RADEON_FRAME_RATE_CONTROL, drm_radeon_frame_rate_control_t)


    ich glaube der patch ist da, oder?


    Ja, der Patch ist wohl da.
    Ein anderer Versuch wäre es, nun folgende Befehle abzuarbeiten:

    Code
    rmmod radeon
rmmod drm
insmod [...]./linux-core/drm.ko
insmod [...]./linux-core/radeon.ko


    So sollten dann auf jeden Fall die gepatchten Module verwandt werden. Das ganze musst du mit beendetem X-Server machen.
    Du kannst das auch etwas nachvollziehen, indem du dmesg nach dem Entfernen und Neuladen der Module aufrufst.




    So long.

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2; DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

    Einmal editiert, zuletzt von Hitman47 ()

    also ich habs hinbekommen, der Mode 4 läuft auch, war wohl ein Fehler bei der Installation von libdrm2.


    Mit dem Parameter "xineliboutput.Advanced.LiveModeSync = 0" in der setup.conf bekomme ich jetzt eine wesentlich stabiler wirkende Regelung.
    Das Flimmern ist leider nicht verschwunden.
    Mit eingeschaltetem Deinterleacer ist das Bild aber jetzt recht gut (das war es vorher auch nicht).


    Kann ich evtl die Regelung jetzt noch optimieren, um das Flimmern in den Bewegnungen wegzubekommen?
    Anbei mal wieder ein xorg0.log bei ausgeschaltetem Deinterleacer und FRC Mode 4.



    Edit:
    Wenn man den Mode vier einige längere Zeit laufen lässt, erscheint irgendwann:

    Code
    frame rate control disabled
field delay error 1600 usec 0 -> 51!!!
field delay error 1600 usec 0 -> 51!!!

    Dateien

    Xorg0.txt 49,1 kB – 162 Downloads

    VDR: Mainboard: MSI B85M-G43; CPU: Pentium G3250 (Haswell); NVIDIA GT630 (GK208 Kepler); SanDisk SSD 64GB SDSSDP-064G-G25 + 500 GB HD; TV: DD Cine CT V6 - Twin Tuner Karte DVB-C (PCI Express Karte); atric USB eco Einschalter

    3 Mal editiert, zuletzt von avanix ()

    Zitat

    Original von avanix
    also ich habs hinbekommen, der Mode 4 luft auch, war wohl ein Fehler bei der Installation von libdrm2.


    Mit dem Parameter "xineliboutput.Advanced.LiveModeSync = 0" in der setup.conf bekomme ich jetzt eine wesentlich stabiler wirkende Regelung.
    Das Flimmern ist leider nicht verschwunden.
    Mit eingeschaltetem Deinterleacer ist das Bild aber jetzt recht gut (das war es vorher auch nicht).


    Kann ich evtl die Regelung jetzt noch optimieren, um das Flimmern in den Bewegnungen wegzubekommen?


    Bezüglich des Flimmern wende bitte mal zusätzlich den Patch im Anhang auf den radeon-Treiber xf86-video-ati an.


    Zitat

    Original von avanix
    Wenn man den Mode vier einige lngere Zeit laufen lsst, erscheint irgendwann:

    Code
    frame rate control disabled
field delay error 1600 usec 0 -> 51!!!
field delay error 1600 usec 0 -> 51!!!


    Anscheinend wird der Prozess der Video-Ausgabe hier im Ablauf massiv unterbrochen was dazu führt das die Rate der angelieferten Frames zu weit von den 25Hz abweicht und sich dadurch die Regelung deaktiviert. Auch der usleep() im field delay controller kommt viel zu spät zurück so das die Videoausgabe schon mindestens ein field weiter ist als sie sein sollte.
    Hohe Systemlast? Irgendein Treiber den den kernel scheduler zu lange behindert?


    Gruss durchflieger

    Hallo durchflieger,


    Zitat

    Original von durchflieger
    Anscheinend wird der Prozess der Video-Ausgabe hier im Ablauf massiv unterbrochen was dazu führt das die Rate der angelieferten Frames zu weit von den 25Hz abweicht und sich dadurch die Regelung deaktiviert. Auch der usleep() im field delay controller kommt viel zu spät zurück so das die Videoausgabe schon mindestens ein field weiter ist als sie sein sollte.
    Hohe Systemlast? Irgendein Treiber den den kernel scheduler zu lange behindert?


    eigentlich nicht, das System ist frisch, die CPU langweilt sich meist mit 5-8%.
    Treiber sind bisher nur ein aktueller Realtek audio Treiber und ein dibcom0700 Treiber für den USB-Stick drauf.
    Irgendwas könnte aber mit Interrupts sein, Auszug aus dmesg:


    Kannst du mir kurz erklären, wie ich den Patch richtig auf den Ati-Treiber anwende? Sorry, bin da ein wenig unbedarft.


    Danke für die Mühe.

    VDR: Mainboard: MSI B85M-G43; CPU: Pentium G3250 (Haswell); NVIDIA GT630 (GK208 Kepler); SanDisk SSD 64GB SDSSDP-064G-G25 + 500 GB HD; TV: DD Cine CT V6 - Twin Tuner Karte DVB-C (PCI Express Karte); atric USB eco Einschalter

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden