Die Änderung auf 22 hat nicht geändert, ich habe immer noch die selben unreglmässigen Ruckler auf den SD Kanälen. Kann es natürlich nicht garantieren, aber für mich sieht das nach deinterlacer aus.
Wie bekomme ich ein lauffähiges System für xineliboutput mit vdpau?
- wbreu
- Geschlossen
-
-
@eisbär
Poste doch mal bitte deine config-Datei von xineliboutput - danke. Verwendest du das lokale oder das remote-Frontend? Gibt's Logeinträge bei den "Sprüngen"? Welche xine-lib-Version nutzt du?
Viele Grüße
Dirk -
Hier die gewünschten Informationen zu meiner Konfiguration:
Die aktiven .xine Einträge:
Code
Alles anzeigen#device used for mono output # string, default: default audio.device.alsa_default_device:iec958 # device used for stereo output # string, default: plug:front:default audio.device.alsa_front_device:iec958 # device used for 5.1-channel output # string, default: iec958:AES0=0x6,AES1=0x82,AES2=0x0,AES3=0x2 audio.device.alsa_passthrough_device:iec958 # device used for 5.1-channel output # string, default: plug:surround51:0 audio.device.alsa_surround51_device:iec958 # speaker arrangement # { Mono 1.0 Stereo 2.0 Headphones 2.0 Stereo 2.1 Surround 3.0 Surround 4.0 Surround 4.1 Surround 5.0 Surround 5.1 Surround 6.0 Surround 6.1 Surround 7.1 Pass Through }, default: 1 audio.output.speaker_arrangement:Pass Through # method to sync audio and video # { metronom feedback resample }, default: 0 audio.synchronization.av_sync_method:resample # vdpau: HD deinterlace method # { bob half temporal half temporal_spatial temporal temporal_spatial }, default: 3 video.output.vdpau_deinterlace_method:bob # vdpau: disable deinterlacing when progressive_frame flag is set # bool, default: 0 video.output.vdpau_honor_progressive:1 # vdpau: restrict enabling video properties for SD video only # { none noise sharpness noise+sharpness }, default: 0 video.output.vdpau_sd_only_properties:noise+sharpness # FFmpeg video decoding thread count # numeric, default: 1 video.processing.ffmpeg_thread_count:2 # number of buffers for HD content # numeric, default: 2500 media.xvdr.num_buffers_hd:4000 # SRC tuning step # numeric, default: 5000 media.xvdr.scr_tuning_step:150 # number of audio buffers # numeric, default: 230 engine.buffers.audio_num_buffers:500 # number of video buffers # numeric, default: 500 engine.buffers.video_num_buffers:250 # default number of video frames # numeric, default: 15 engine.buffers.video_num_frames:22
Ich verwende ein remote vdr-sxfe (aber natürlich auf dem selben Rechner) mit folgenden Versionen (alles aus dem e-tobi Reposatory und dann selber Compiliert): vdr-1.7.9, vdr-plugin-xineliboutput_1.0.4+cvs20090826.1640-1etobi1, xine-lib_1.1.16.3-1etobi10.
Mein vdr-sxfe Aufruf sieht wie folgt aus:
Codeusr/bin/vdr-sxfe xvdr:tcp://localhost:37890 --video=vdpau --audio=alsa:iec958 --nokbd --lirc --fullscreen --reconnect --syslog --post tvtime:method=use_vo_driver
Das Grafikkarten Treiber setzte ich 190.18 ein.
-
Hallo,
ich habe noch folgenden Vorschlag für die Anleitung im ersten Artikel dieses Thread. Die xine config parameter die durch meine Patches ergänzt werden sind etwas mager beschrieben:
Die Einstellparameter "noise reduction" und "sharpness" im xineliboutput setup werden standardmäßig bei SD UND HD-Videos angewendet.
Mit der xine config Einstellung "video.output.vdpau_sd_only_properties:noise+sharpness" wirken die Einstellparameter nur noch bei SD-Videos. Bei HD-Videos wird in der Regel keine "Nachbesserung" benötigt und das Abschalten spart natürlich Rechenleistung in der GPU.Weiterhin sollte man die Display-Queuelänge vergrössern mit der xine config Einstellung "video.output.vdpau_display_queue_length=4".
Damit sollte die Wiedergabe ruckelfreier während eines aktiven "grabbing" laufen. Eventuell bringts auch was bei der normalen Wiedergabe ohne aktiven "grabbing".
Gruss durchflieger -
Noise reduction und sharpening sind sowieso ein no-go bei gutem Quellmaterial! Rauschunterdrückung produziert praktisch immer mühsame Artefakte wie eine Unschärfe in bewegten Flächen (z.B. sieht man keine Struktur auf der Haut der Darsteller, solange sie ihren Kopf bewegen, Details erscheinen erst, wenn das Gesicht still gehalten wird). Die Doppelkanten bei zu starkem Nachschärfen (siehe "Unscharf maskieren" in Photoshop, dort kann man das gut ausprobieren) sind noch viel deutlicher zu sehen.
Leider werden immer wieder sogar digitale Negative (Digital Intermediates - DI) von Hollywood-Filmen derart nachbearbeitet und dadurch deren Bildqualität nicht verbessert, sondern teilweise faktisch zerstört! Das sieht man besonders gut im digitalen Kino oder auf Blu-rays.
Das einzige richtige Mittel zur guten Darstellung von natürlich rauschendem Bildmaterial (= Filmkorn) ist eine hohe Datenrate beim Encoding. Das geht halt leider bei DVB oder Internetvideos häufig weniger gut als auf der Blu-ray Disk, wo man höhere Reserven für die Datenrate hat...
(sorry für OT - musste nur klarmachen, warum noise reduction und sharpening an sich evil sind! )
-
Zitat
Original von durchflieger
Hallo,ich habe noch folgenden Vorschlag für die Anleitung im ersten Artikel dieses Thread. Die xine config parameter die durch meine Patches ergänzt werden sind etwas mager beschrieben:
Die Einstellparameter "noise reduction" und "sharpness" im xineliboutput setup werden standardmäßig bei SD UND HD-Videos angewendet.
Mit der xine config Einstellung "video.output.vdpau_sd_only_properties:noise+sharpness" wirken die Einstellparameter nur noch bei SD-Videos. Bei HD-Videos wird in der Regel keine "Nachbesserung" benötigt und das Abschalten spart natürlich Rechenleistung in der GPU.Weiterhin sollte man die Display-Queuelänge vergrössern mit der xine config Einstellung "video.output.vdpau_display_queue_length=4".
Damit sollte die Wiedergabe ruckelfreier während eines aktiven "grabbing" laufen. Eventuell bringts auch was bei der normalen Wiedergabe ohne aktiven "grabbing".
Gruss durchfliegerHi durchflieger,
habe deine Anmerkungen gerade an geeigneter Stelle (config_xineliboutput) ergänzt.
Ich hätte noch eine Bitte an dich, neue Patches für die xineliboutput-cvs in Verbindung mit xine-vdpau-r281 wären super.
Gruß
Wolfgang -
-
Hi,
ein kurzer Hinweis von meiner Seite. Wenn man die Öffentlich-Rechtlichen via T-Home Entertain schaut, sollte das Flag honor_progressive auf 0 stehen. Mir scheint so, als ob die interlaced Material senden, aber das Progressive Flag setzen! Jedenfalls sieht ansonsten das Bild reichlich "zerfranst" aus!
Code# vdpau: disable deinterlacing when progressive_frame flag is set # bool, default: 0 #video.output.vdpau_honor_progressive:0
Gruß,
Space
-
Hi Wolfgang,
von mir auch ein herzliches Dankeschoen fuer deine top Arbeit hier! Dieser Thread spart so einige
Zeit beim Aufsetzen des Systems, da alles so schoen zusammengefasst ist. Mit fundierten
Erklaerungen, weiter so!- sparkie
PS: vielen Dank auch an durchflieger, wenn er hier mitliest, fuer seine wichtigen VDPAU-Erweiterungspatches. Vielleicht koennen wir mal irgendwann
wieder was zusammen entwickeln. Unsere Framerate-Patches werden in VDPAU-Zeiten ja nicht mehr so dringend gebraucht -
einen merkwuerdigen Effekt habe ich noch mit der xorg.conf modeline-config:
Hardware: ASUS EN8400GS SILENT/HTP/512M GeForce 8400 GS 512MB (siehe z.B. hier http://www.newegg.com/Product/…aspx?Item=N82E16814121235)
Treiber: x86_64-185.18.36 [UPDATE: gilt auch fuer x86_64-190.36]mit dieser xorg.conf:
Code
Alles anzeigenSection "Monitor" Identifier "Monitor0" EndSection Section "Device" Identifier "Device0" Driver "nvidia" Option "ModeDebug" "True" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Modes "1920x1080_50" EndSubSection EndSection Section "Extensions" Option "Composite" "Disable" EndSection
wird das Display statt mit 50 mit 60Hz angesteuert:
Code7751 root@yuma[VDR-1.7.0/root] > DISPLAY=:0 nvidia-settings --query RefreshRate Attribute 'RefreshRate' (yuma:0.0; display device: DFP-0): 60.00 Hz.
und das, obwohl in der Xorg.0.log ausdruecklich gesagt wird:
Code
Alles anzeigen[...] (II) NVIDIA(0): Validating Mode "1920x1080": (II) NVIDIA(0): 1920 x 1080 @ 50 Hz (II) NVIDIA(0): For use as DFP backend. (II) NVIDIA(0): Mode Source: EDID (II) NVIDIA(0): Pixel Clock : 148.50 MHz (II) NVIDIA(0): HRes, HSyncStart : 1920, 2448 (II) NVIDIA(0): HSyncEnd, HTotal : 2492, 2640 (II) NVIDIA(0): VRes, VSyncStart : 1080, 1084 (II) NVIDIA(0): VSyncEnd, VTotal : 1089, 1125 (II) NVIDIA(0): H/V Polarity : +/+ (II) NVIDIA(0): Mode is valid. [...] (II) NVIDIA(0): "1920x1080_50" : 1920 x 1080 @ 50.0 Hz (from: EDID) [...] (II) NVIDIA(0): Config Options in the README. (II) NVIDIA(0): Setting mode "1920x1080_50" (II) Loading extension NV-GLX
Wenn ich hingegen exakt die gleichen EDID Parameter von Hand in die xorg.conf uebertrage und EDID deaktiviere:
Code
Alles anzeigenSection "Monitor" Identifier "Monitor0" HorizSync 50.0 - 60.0 VertRefresh 50.0 Option "ExactModeTimingsDVI" "true" Option "UseEDID" "false" ModeLine "1920x1080@50p" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync EndSection Section "Device" Identifier "Device0" Driver "nvidia" Option "ModeDebug" "True" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Modes "1920x1080@50p" EndSubSection EndSection Section "Extensions" Option "Composite" "Disable" EndSection
funktioniert es wie es soll:
Code7760 root@yuma[src/vdr-xineliboutput-cvs-20090926163500] > DISPLAY=:0 nvidia-settings --query RefreshRate Attribute 'RefreshRate' (yuma:0.0; display device: DFP-0): 50.00 Hz.
was auch sofort an den perfekten Laufschriften erkennbar ist (fuer SD Content mit VDPAU ist die Karte uebrigens durchaus eine Empfehlung)
Also nicht wundern, wenn es trotz Auswahl eines 50Hz 'Modes' ruckeln sollte.
Ist wohl noch 'nen Treiber-Bug:)
TIPS:
- EDID Timings von Hand in die xorg.conf uebertragen und EDID deaktivieren.
- immer mit 'nvidia-settings' kontrollieren, ob auch wirklich die richtigen Timings genutzt werden- sparkie
-
Dar bei mir auch so. Use EDID Freqs o.ä. mußte ich rausnehmen und die Modeline manuell setzen um auf 50Hz zu kommen...
-
Ein gutes hat VdPau für mich jedenfalls jetzt schon: ich beginne zu verstehen, wie die xorg.conf funktioniert...
Nur daß mir das nix nützt, glaube ich.
Damit ich ein flüssiges Bild (ohne Ruckler und Aussetzer) hinbekomme, im Moment noch SD, muß ich eine 50Hz-Modeline hinbekommen, richtig? Jedenfalls wird die Ausgabe immer besser, je näher ich den 50 Hz komme.Code
Alles anzeigenSection "Monitor" #++LG Electronics Inc.; LG M1910A; GSM4AA7; 30.0-83.0; 56.0-75.0; 1 Identifier "Monitor0" VendorName "LG" ModelName "M1910A" HorizSync 30.0 - 83.0 VertRefresh 56.0 - 75.0 Option "DPMS" ModeLine "640x480@60" 25.2 640 656 752 800 480 490 492 525 -hsync -vsync ModeLine "640x480@72" 31.5 640 664 704 832 480 489 491 520 -hsync -vsync ModeLine "640x480@75" 31.5 640 656 720 840 480 481 484 500 -hsync -vsync ModeLine "800x600@56" 36.0 800 824 896 1024 600 601 603 625 +hsync +vsync ModeLine "800x600@72" 50.0 800 856 976 1040 600 637 643 666 +hsync +vsync ModeLine "800x600@75" 49.5 800 816 896 1056 600 601 604 625 +hsync +vsync ModeLine "800x600@60" 40.0 800 840 968 1056 600 601 605 628 +hsync +vsync ModeLine "832x624@75" 57.3 832 864 928 1152 624 625 628 667 -hsync -vsync # modeline "1024x768@75Hz" 78.750 1024 1040 1136 1312 768 769 772 800 +HSync +VSync ModeLine "1024x768@75" 78.8 1024 1040 1136 1312 768 769 772 800 +hsync +vsync ModeLine "1024x768@70" 75.0 1024 1048 1184 1328 768 771 777 806 -hsync -vsync # modeline "1024x768@60Hz" 65.000 1024 1048 1184 1344 768 771 777 806 -HSync -VSync ModeLine "1024x768@60" 65.0 1024 1048 1184 1344 768 771 777 806 -hsync -vsync ModeLine "1152x864@75" 108.0 1152 1216 1344 1600 864 865 868 900 +hsync +vsync ModeLine "1280x1024@75" 135.0 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync ModeLine "1280x960@60" 102.1 1280 1360 1496 1712 960 961 964 994 -hsync +vsync ModeLine "1280x1024@60" 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync ModeLine "1280x960@75" 129.9 1280 1368 1504 1728 960 961 964 1002 -hsync +vsync
Das ist bei mir die 800x600@56 - und richtig, dann setzt der Ton nur noch alle 90s mal aus. Die 60er Modi gehen einigermaßen...
Muß ich mir einen neuen Monitor zuzulegen? Einen, der bis VertRefresh < 50 kommt? Den Hinweis habe ich bisher jedenfalls noch nirgends hier gefunden...Gruß, Bernd
-
Hallo Bernd,
richtig, eine Modeline mit moeglichst exakt 50Hz ist minimale Voraussetzung fuer ein flüssiges Bild.
Dabei immer mit 'nvidia-settings --query RefreshRate' pruefen was tatsaechlich fuer ein Refresh genutzt wird.
Durch eine falsche Modeline
koennen jedoch keine Tonaussetzer verursacht werden. Evtl. kannst du mal den Patch hier testen, ob er dein
Problem behebt.- sparkie
-
Hallo Sparkie,
da ich die Pakete von Tobi verwende, ist der Patch schon drin, ok, nicht die letzte Version, aber bis zum 25.08.
Wie ich bisher zusammengelesen und hoffentlich richtig verstanden habe, laufen durch die unterschiedlichen Frequenzen Bild und Ton auseinander, und wenn das lange genug passiert ist, wird snchronisiert (= Bild angehalten) und das Spiel geht von vorne los. Bei digitalem Tonausgang gibt's dann gleich auch noch Aussetzer im Ton, wharscheinlich initialiert vdr-sxfe alsa=spdif gleich mit.
Hilft wohl nur ein neuer Monitor. -
Hallo,
genau wie Eisbaer128 habe auch ich auf SD Sendern Ruckler. Nicht auf allen sendern und auch nicht immer. Hat wohl wirklich etwas mit dem Deinterlancer zu tun. Ohne Deinterlancing läuft alles flüssig.
Hier meine config_xineliboutput:
Code
Alles anzeigenaudio.device.alsa_front_device:plug:hdmi audio.device.alsa_passthrough_device:plug:hdmi audio.device.alsa_surround51_device:plug:hdmi audio.output.speaker_arrangement:Pass Through audio.synchronization.av_sync_method:resample audio.synchronization.force_rate:48000 audio.synchronization.resample_mode:on video.output.vdpau_deinterlace_method:bob video.output.vdpau_honor_progressive:1 video.output.vdpau_sd_only_properties:noise+sharpness video.output.vdpau_display_queue_length=4 media.xvdr.num_buffers_hd:4000 media.xvdr.scr_tuning_step:50 engine.buffers.audio_num_buffers:500 engine.buffers.video_num_buffers:2500 engine.buffers.video_num_frames:22
vdr1.7.9
xineliboutput-CVS vom 30.09.09 ohne DF-Patch
xine-vdpau-r284 ohne DF-Patchmfg
iby -
-
Zitat
Original von wbreu
Auf ION-Systeme gehe ich hier nicht ein, da diese System in meinen Augen noch zu viele Einschränkungen für einen vollwertigen VDR mitbringen,
bzw. eben zu wenige PCI/PCI-Express-Steckplätze mitbringen oder auch keine LPT- oder seriellen Schnittstellen haben.Sorry, wenn es hier nicht ganz passt und ich einfach so rein platze, das mit den wenigen Steckplätzen kann ich nachvollziehen, wenn man alle Freiheiten zur Erweiterung haben will. Aber wofür brauche ich so dringend eine parallele und/oder serielle Schnittstelle?
Gruß Sindbad6
-
Zitat
Original von sindbad6
Sorry, wenn es hier nicht ganz passt und ich einfach so rein platze, das mit den wenigen Steckplätzen kann ich nachvollziehen, wenn man alle Freiheiten zur Erweiterung haben will. Aber wofür brauche ich so dringend eine parallele und/oder serielle Schnittstelle?
Gruß Sindbad6
Hi,
zwei Beispiele:
Seriell => Atric-Einschalter mit Lirc-Schnittstelle
LPT => Grafisches LCD-Display für die Kanalanzeige usw.
Gruß
Wolfgang -
-
hallo wbreu.
ist 2.4.4.1 weiterhin dein Favorit oder ist 2.4.4.2 mitlerweile Stabil.
Gruß Georg
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!