Hallo Wolfgang,
habe den gleichen Softwarestand aber AMD
ZitatMeine momentane config:
- xine-vdpau r226
- nvidia 180.29
- xineliboutput-1.0.4
aber leider noch ein leichtes ruckeln bei Anixe + AstraHD
kannst du mal deine config_xineliboutput posten?
Bitkit
Hallo,
hier mal meine aktuelle config.
Wolfgang
Bei dir läuft BOB. Was passiiert bei temporal?
Hi das hier passeirt beim Umschalten auf..
1. Astra HD:
vo_vdpau: recreate mixer to match frames: width=1920, height=1080, chroma=0
vo_vdpau: enabled features: temporal=1, temporal_spatial=0
vo_vdpau: enabled features: inverse_telecine=0
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: vdpau_update_csc: hue=0.000000, saturation=1.000000, contrast=1.000000, brightness=0.000000, color_standard=1
vo_vdpau: update_frame - destroy surface
video_out: Verwerfe Bild mit pts 120435702, weil es zu alt ist (Unterschied: 16432).
video_out: Verwerfe Bild mit pts 120423102, weil es zu alt ist (Unterschied: 29032).
video_out: Verwerfe Bild mit pts 120427782, weil es zu alt ist (Unterschied: 24352).
video_out: Verwerfe Bild mit pts 120432426, weil es zu alt ist (Unterschied: 19708).
video_out: Verwerfe Bild mit pts 120437035, weil es zu alt ist (Unterschied: 15991).
video_out: Verwerfe Bild mit pts 120441610, weil es zu alt ist (Unterschied: 13198).
video_out: Verwerfe Bild mit pts 120446153, weil es zu alt ist (Unterschied: 11339).
video_out: Verwerfe Bild mit pts 120450664, weil es zu alt ist (Unterschied: 7719).
video_out: Verwerfe Bild mit pts 120455145, weil es zu alt ist (Unterschied: 5020).
video_out: Verwerfe Bild mit pts 120459596, weil es zu alt ist (Unterschied: 8588).
video_out: Verwerfe Bild mit pts 120477127, weil es zu alt ist (Unterschied: 8332).
video_out: Verwerfe Bild mit pts 120481446, weil es zu alt ist (Unterschied: 4915).
video_out: Verwerfe Bild mit pts 120485741, weil es zu alt ist (Unterschied: 8550).
video_out: Verwerfe Bild mit pts 120490013, weil es zu alt ist (Unterschied: 5157).
video_out: Verwerfe Bild mit pts 120498490, weil es zu alt ist (Unterschied: 4368).
video_out: Verwerfe Bild mit pts 120551776, weil es zu alt ist (Unterschied: 4310).
2. Anixe HD
vdpau_h264_reset
dpb_free_all, used: 0
prebuffer=14400 pts
dpb_free_all, used: 0
vdpau_set_property: property=0, value=0
vo_vdpau: enabled features: temporal=0, temporal_spatial=0
prebuffer=14400 pts
vdpau_set_property: property=0, value=1
vo_vdpau: enabled features: temporal=1, temporal_spatial=0
Allocate 4 reference frames
Create decoder: vdp_device: 1, profile: 8, res: 1920x1080
video_out: Verwerfe Bild mit pts 120684268, weil es zu alt ist (Unterschied: 17028).
video_out: Verwerfe Bild mit pts 120671668, weil es zu alt ist (Unterschied: 29628).
video_out: Verwerfe Bild mit pts 120676348, weil es zu alt ist (Unterschied: 24948).
video_out: Verwerfe Bild mit pts 120680992, weil es zu alt ist (Unterschied: 20304).
video_out: Verwerfe Bild mit pts 120685601, weil es zu alt ist (Unterschied: 15695).
video_out: Verwerfe Bild mit pts 120690176, weil es zu alt ist (Unterschied: 12902).
video_out: Verwerfe Bild mit pts 120694719, weil es zu alt ist (Unterschied: 10141).
video_out: Verwerfe Bild mit pts 120699230, weil es zu alt ist (Unterschied: 6521).
video_out: Verwerfe Bild mit pts 120703711, weil es zu alt ist (Unterschied: 4723).
video_out: Verwerfe Bild mit pts 120725693, weil es zu alt ist (Unterschied: 8062).
video_out: Verwerfe Bild mit pts 120730012, weil es zu alt ist (Unterschied: 4607).
Alles klar!?
Mir reicht der temporal voll aus, ich kann keinen Unterschied zu temporal_spatial erkennen.
Gruß
Wolfgang
Aus Deiner config:
# vdpau: HD deinterlace method
# { bob temporal temporal_spatial }, default: 1
#video.output.vdpau_deinterlace_method:temporal
Danach müßte bob laufen da default, es läuft aber temporal.
Ich habe übrigens genau die gleiche Ausgabe bei gleicher config.
PS: Habe gerade mal auf xinebiboutput 1.0.4 upgedated. Die Mikroruckler sind jetzt weg, warum auch immer?? Aber ich traue der Sache noch nicht so ganz, mal sehen wie es morgen ist.
Hi,
eine Frage zu vdpau:
Laut vdr-ml:
ZitatAndy Ritger (nvidia) said in a mail to the xorg mailing list some time ago;
"If the application doesn't enable de-interlacing, NVIDIA's VDPAU implementation will currently copy the weaved frame to the "progressive" surface,
and whether it will come out correctly will depend whether the window's offset from the start of the screen is odd or even."
I take this to imply that field parity should be possible, but the application in use have to detect the field flag from the source material and
set the Y offset appropriately to be 0 or 1 accordingly.
Progressive material seems to display correctly. -- Torgeir Veimo
Wenn ich das richtig verstehe, dann könnte man 1080i mittels vdpau auch interlaced mit 1080i ausgeben und den HD-TV das deinterlacing machen lassen.
So würde man die Vorteile von vdpau ohne viel Stromverbrauch seitens der Graka bekommen - oder?
Grüße
Funzt
Hi Funzt,
ZitatOriginally posted by Funzt
Wenn ich das richtig verstehe, dann könnte man 1080i mittels vdpau auch interlaced mit 1080i ausgeben und den HD-TV das deinterlacing machen lassen.
das sieht ganz so aus. Das waere dann sicher optimal.
Aber es kann nur funktionieren, wenn absolute Synchronitaet zwischen
Stream und DVI/HDMI Timing erreicht wuerde. Da man ansonsten bei eventuellem Fieldverlust nicht einfach on-the-fly mal eben die Fieldpolarity drehen kann.
Im Endeffekt genau die gleiche Problematik wie bei PAL und den FRC Patches von durchflieger und mir.
Ich bin im Moment leider noch zu sehr mit der Integration der FRC Patches fuer SCART/VGA in easy-vdr beschaeftigt.
Sonst koennte ich mich mal nach langer Zeit wieder um HDTV kuemmern.
Lang wird's aber eh nicht mehr dauern, wenn ich sehe was ihr hier so treibt:)
- sparkie
ZitatAlles anzeigenOriginally posted by dad401
Also, hier meine neuesten Erkenntnisse (u.a. auch dank Hilfe der Nutzer im IRC-Channel #xine-vdpau).
Die neue Version xine-vdpau (rev. 157) sowie der NVIDIA-Treiber 180.22 machen weiter Fortschritte. Meine verbleibenden Probleme sind hierbei:
- ab und an Artefakte und/oder irgendein merkwürdiges, grünes (oder buntes) Zwischenframe (ich glaube dort ?LOMIX? oder sowas zu erkennen)
- 100% ruckelfrei wie PAL damit noch nicht
Das beste war jedoch, dass ich jetzt weiss, warum lange Zeit während all meiner Tests ANIXE und ASTRA HD nicht liefen. Das Problem konnte behoben werden, als ich die SLI Framebuffer Size im BIOS für die Graka von 128 auf 256 (maximaler Wert) erhöht hatte. Der Fehler wurde in den Logmeldungen von vdpau zwar gemeldet (in etwa: Ressourcen nicht ausreichend verfügbar), ich konnte diesen jedoch nicht zuordnen.
Nun klappt auch ANIXE und ASTRA
Neben vdr-sxfe habe ich auch xine-ui ausprobiert. Leider kann ich damit nicht auf das OSD über die Tastatur zugreifen. Liegt aber evtl. daran, dass ich nur das xineliboutput-Plugin nutze (Aufruf von xine mit: "xine xvdr://") und vdr-xine nicht verwende.
Bisher habe ich zum Testen immer VDR 1.7.0 verwendet (mit Patch für S2-liplianin API). Mich würde mal interessieren, ob jemand vdr-sxfe/xine mit VDR >= 1.7.1 zum Laufen gebracht hat. Meiner Meinung nach geht das ohne Patch wohl nicht, weil dort das Format (TS statt PES) geändert wurde und xine damit (noch?) nicht klar kommt.
Hat hierzu evtl. jemand weitere Informationen? -> [EDIT] Dies stimmt soweit, siehe hier
Gruss
Marcus
Gutenmittag,
Ich bin soweit das es auch functioniert mit vdr-1.7.2. (S2API) und der extensionpatch #66. Der Livebuffer muss immer activiert sein, sonst geht es nicht.
Sobald ich "Display aspect = CenterCutOut" einstell wird es hell.
M fr gr,
Carel
Hallo,
hier mal mein Erfahrungsbericht:
Habe mal vdr 1.7.2 mit vdpau installiert und mich dabei grob an diese Anleitung gehalten.
Allerdings stammt mein NVidia Treiber und die vdpau Sachen (180.29) aus einem Repository - hab den Link grad nicht parat aber ich poste ihn später nochmal.
Nach einigen weiteren aus dem Forum zusammengesammelten Tipps (Änderungen in der config von xineliboutput, Deaktivieren der Component Option in der xorg.cong usw) läuft nun SD- und HD-TV per vdpau. Die CPU-Last ist tatsächlich um einiges niedriger, aber nicht so gering wie erhofft. Wahrscheinlich, weil ich nach wie vor das tvtime Deinterlacing im nicht-cheap-mode an habe. Zudem habe ich bei SD-TV alle paar Sekunden "Mikroruckler" und nach einigen Senderwechseln ist das Bild nur noch eine Suppe aus grünen und grauen Flächen und Schnipseln des Fernsehbildes. Da hilft dann nur noch ein Neustart des Frontends. Arte HD und Anxie HD laufen mehr oder weniger flüssig, bei Anxie fehlt allerdings der Ton und man sieht deutliche Kompressionsartefakte, bzw vereinzelt grobe Blöcke an den Konturen. Der Astra HD Demosender läuft irgendwie nicht gerade nicht flüssig.
Ich nutze nun wieder xv für die Ausgabe und verzichte auf die HD-Sender (sind ja eh nicht grad viele), aber immerhin ist es ein kleines Erfolgserlebnis, dass es überhaupt läuft. Wird wohl noch eine Weile dauern, bis das Zeugs out-of-the box läuft, bis dahin gibts ja vielleicht auch schon weitere HD-Sender 
Meine Konfiguration:
- Abit A-N78HD (GeForce 8200 OnBoard)
- AMD Athlon X2 4850e
- Hauppauge NOVA-HD-S2
- Ubuntu 8.10 64-Bit
ZitatOriginal von NeoTrantor
"Mikroruckler" und nach einigen Senderwechseln ist das Bild nur noch eine Suppe aus grünen und grauen Flächen und Schnipseln des Fernsehbildes. Da hilft dann nur noch ein Neustart des Frontends.
Du hast wahrscheinlich in den xineliboutput-Settings Softwarescaling
fürs OSD aktiviert, wenn ich das bei mir abschalte dann tritt das nicht
mehr auf.
Gerald
Ja das scheint zu helfen, zumindest gegen die Bildfehler. Allerdings ist das Hardware OSD offenbar ziemlich rechenaufwendig, es ist jedenfalls recht langsam und beim Drücken einer Taste auf der Fernbedienung bleibt das Bild kurz stehen.
ZitatOriginal von NeoTrantor
Ja das scheint zu helfen, zumindest gegen die Bildfehler. Allerdings ist das Hardware OSD offenbar ziemlich rechenaufwendig, es ist jedenfalls recht langsam und beim Drücken einer Taste auf der Fernbedienung bleibt das Bild kurz stehen.
Hat vermutlich andere Ursachen, mein Rechner ist schwächer als deiner und ich habe das Problem nicht,
allerdings habe ich im Moment nur SDTV, tritt das nur bei HDTV auf?
Gerald
Neue xine-lib-1.2 - vdpau r234 patch von rnissl....
http://www.jusst.de/vdpau/file…b-1.2-vdpau-r235.diff.bz2
Bye,
Carel
Nein bei SDTV. Werde mal etwas herumexperimentieren woran es liegen könnte...
Hallo,
ich verwende hier cpufreqd um meine CPU herunterzutakten. Dabei ist mir aufgefallen, dass ich bei Verwendung von cpufreqd (d.h. 1GHz statt 2,5GHz), merkwürdige Streifen bei Anixe HD habe (lokal, ähnlich wie Interlacing). Habe dies in einen obigen Post schon einmal beschrieben.
Nach Deaktivierung bzw. beim Setzen auf 2,5GHz sind diese Streifen m.E. weg. Kennt jemand ggf. auch das Problem, bzw. kann es nachvollziehen?
SW: aktuelles VDPAU, Xineliboutput 1.0.4, Sonstiges siehe Sig
Marcus
gibt es eigentlich eine möglichkeit das deinterlacing vom Plasma Fernseher handeln zu lassen ?
Wenn man in der xorg.conf unter Monitors den Parameter "Option "UseEdidFreqs" "FALSE"" setzt, gibt die Karte 1080i aus.
ZitatOriginally posted by ReD_AvEnGeR
gibt es eigentlich eine möglichkeit das deinterlacing vom Plasma Fernseher handeln zu lassen ?
das waere eine interessante Variante. Abhaengig davon, wie gut/schlecht die TV-internen Deinterlacer im Vergleich zu den nVidia GraKa-Deinterlacern sind.
ohne FrameRateControl Patches kann das aber nicht gehen. Da in den Interlaced-Fields sowohl raeumliche als auch zeitliche Information steckt kann man sich hier keinen Fieldverlust erlauben.
Es wuerden sonst bis zum naechsten Fieldverlust Even und Odd vertauscht wiedergegeben werden.
Von nVidia wird so eine Loesung nicht zu erwarten sein. Man muss also per vdpau decodieren und auf einer FRC-faehigen Grafik (ATI Radeon oder Intel i9xx Chips) ausgeben.
Durchflieger hat ja hier schon eine Loesungsmoeglichkeit kurz beschrieben
Ich habe inzwischen Tests ueber DVI/HDMI mit intel-basierenden Chipsaetzen durchgefuehrt.
Mit meiner aktuellen Patchversion funktioniert FRC/DVI/HDMI bis auf eine kleine Aenderung auf meinem Pundit P1-P5945GC bereits einwandfrei.
Es sollten sich alle Motherboards mit i9xx Onboard Grafik eignen. Vorausgesetzt natuerlich der DVI SDVO Port ist bestueckt.
Getestet habe ich jedoch noch mit SD. Wird Zeit, dass ich mich auch mal um vdpau kuemmere:)
- sparkie
Hi zusammen,
jepp genau so wie ReD_AvEnGeR das oben anspricht, ist meiner Meinung nach die beste Variante.
Mit ner 50 Hz-Modeline die Bildausgabe an den LCD, das kann man schön im xorg.log ansehen oder mit xrandr auch bei laufendem X-Server einstellen/überprüfen.
Wobei ich sagen muß, ich kann keinen Unterschied feststellen, wenn der LCD das Deinterlacing macht oder die Grafikkarte. Soll heissen, egal ob mit 50 Hz oder mit 60 Hz. Bei Laufschriften sieht man halt dass die 50 Hz-Modeline enorme Vorteile hat, da die wesentlich weniger Ruckeln.
Die Aufbereitung macht vdpau mittlerweile super gut und sehr CPU-lastschonend.
Ab und zu kann man im log beobachten dass Frames geskipped werden, dann ruckelts kurz, das kann aber andere Ursachen haben.
Bei SDTV kommt das nie vor!
Wolfgang
Hi Wolfgang
ZitatOriginally posted by wbreu
Wobei ich sagen muß, ich kann keinen Unterschied feststellen, wenn der LCD das Deinterlacing macht oder die Grafikkarte. Soll heissen, egal ob mit 50 Hz oder mit 60 Hz. Bei Laufschriften sieht man halt dass die 50 Hz-Modeline enorme Vorteile hat, da die wesentlich weniger Ruckeln.
heisst das, dass hier jegliches PC-seitige Deinterlacing deaktiviert werden kann? Sorry der Frage ich hab mit vdpau noch nichts gemacht (Schande ueber mich:) )
Nur mit deaktiviertem PC-Deinterlacing wuerde die interlaced Ausgabe ueber HDMI doch richtig SInn machen.
- sparkie
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
