Probiers mit revision 220.
lg
ebsi
Damit baut es jetzt. Danke! Kann aber erst nächste Woche testen, da der spontane Test gestern mit neuem xserver fehlgeschlagen ist.
Probiers mit revision 220.
lg
ebsi
Damit baut es jetzt. Danke! Kann aber erst nächste Woche testen, da der spontane Test gestern mit neuem xserver fehlgeschlagen ist.
So ich melde mich auch mal wieder. War ja zuletzt bei r190 hängengeblieben. Alles danach lief ja bei mir nicht. Jetzt wollte ich heute mal wieder updaten, aber die xine-lib will nicht bauen. Ab r215 erhalte ich beim Bauen folgenden Fehler:
ff_video_decoder.c:136: warning: ‘AVPaletteControl’ is deprecated
ff_video_decoder.c: In function ‘get_buffer’:
ff_video_decoder.c:187: error: ‘AVCodecContext’ has no member named ‘pkt’
ff_video_decoder.c:187: error: ‘AVFrame’ has no member named ‘pkt_pts’
ff_video_decoder.c:187: error: ‘AVCodecContext’ has no member named ‘pkt’
ff_video_decoder.c:188: error: ‘AVFrame’ has no member named ‘pkt_pts’
ff_video_decoder.c: In function ‘ff_handle_special_buffer’:
ff_video_decoder.c:1116: warning: ‘AVPaletteControl’ is deprecated
ff_video_decoder.c:1120: warning: ‘AVPaletteControl’ is deprecated
ff_audio_decoder.c: In function ‘ff_audio_decode_data’:
ff_audio_decoder.c:288: warning: ‘avcodec_decode_audio2’ is deprecated (declared at /usr/include/libavcodec/avcodec.h:3390)
ff_audio_decoder.c:313: warning: ‘avcodec_decode_audio2’ is deprecated (declared at /usr/include/libavcodec/avcodec.h:3390)
Alles anzeigen
Warum xine-ui beim starten abstürzt ist mir ein rätsel.
Also abstürzen tut xine nicht direkt, sondern es hängt beim Start.
Kannst du mal die Verwendeten Software Versionen posten ?
( X + Libs, xine-ui, libva, xf86 intel treibet....) Ich sehe in deiner Signatur das du Suqeeze verwendest. Welche Quellen
hast Du dort eingebunden ? ( /etc/apt/sources.list ). Vielleicht werde ich am Wochenende eine Squeeze zum testen installieren.
Zu meiner Schade muss ich bekennen, dass die Signatur nicht aktuell war. Hatte in den letzten Wochen sehr viel gebastelt und geändert. Ich habe es mal aktualisiert
Zu den Versionen:
X: 1.9.2.901 (ist relativ alt, kann ich bei Zeiten mal aktualisieren; Die ganzen X packages und libs sind aus dem xorg edgers ppa)
libva: GIT von dieser Woche
xf86 intel treiber: GIT von dieser Woche
mesa: GIT von dieser Woche
xine-ui: SVN von dieser Woche
xine-lib-vaapi: r199
Da fällt mir gerade auf, dass ich parallel noch ein Ubuntu 10.10 minimal mit neuerem Kernel und X installiert habe. Das könnte ich noch mal testen.
Grüße und Danke für dein Engagement!
Christoph
Hi ebsi,
hatte jetzt noch mal Zeit zum Testen:
Leider habe ich auch mit der aktuellen Version noch genau die gleichen Probleme: Egal ob ich das softdec aktiviert habe oder nicht, xinestart zeigt nur sporadisch und zufällig mal ein Bild nach dem Start. Es kann passieren, dass ich 5 mal hintereinander ein Bild nach dem Start bekomme und irgendwann geht es dann wieder nicht. Für mich nicht nachvollziehbar. Darüber hinaus raucht xine dann irgendwann auch ab, wenn es mal lief:
Ich kann es mir leider nicht erklären.
Mein xine Aufruf:
/usr/bin/xine -f --post vdr_video --post vdr_audio --post vdr --verbose=2 "vdr:/tmp/vdr-xine/stream#demux:mpeg_pes"
Aber auch mit deinem Aufruf ist das Ergebnis identisch.
Hier noch mal die Ausgabe, von der ich weiter oben mal geschrieben hatte, die auftritt, wenn man xine mit User-Rechten ausführt.
audio_out: thread created
xine_stream_new
video_decoder: can't raise nice priority by 1: Die Operation ist nicht erlaubt
video_out: thread created
video_out: can't raise nice priority by 2: Die Operation ist nicht erlaubt
audio_out: thread created
xine_interface: unknown or deprecated stream param 10 set
xine_stream_new
video_decoder: can't raise nice priority by 1: Die Operation ist nicht erlaubt
xine_interface: unknown or deprecated stream param 10 set
xine_stream_new
video_decoder: can't raise nice priority by 1: Die Operation ist nicht erlaubt
xine_interface: unknown or deprecated stream param 10 set
Alles anzeigen
Bei mir läuft die neue Version auch ohne die beiden Configs nicht. Sehr sporadisch erhalte ich nach dem Xine-Start ein Bild, spätestens nach dem Umschalten bleibt der Bildschirm aber schwarz und Xine hängt. Aufgefallen ist mir noch, dass im xine log etwa steht wie "video_out....no permission to raise nice level". da ich mittlerweile wieder zurück auf r190 kann ich den genauen Wortlaut nicht wiedergeben. Startet man als root bleiben die Ausgaben (sinnigerweise) aus, jedoch ist das oben beschriebene Problem nachwievor vorhanden.
Vorsichtshalber habe ich noch mal den kompletten Treiber Stack und xine-ui aktualisiert, hilft aber auch nicht.
Ich habe die Sourcen von VLC gecheckt. Das dort das Deinterlacing geht ist kein wunder. In VLC passiert es in SOFTWARE. VLC verwendet VAAPI nur für die Decodierung, jedoch nicht für die Anzeige. Wenn Ihr vergleiche macht bitte mit mplayer-vaapi durchführen. mplayer-vaapi ist mehr oder weniger die Referenzimplementierung und besser vergleichbar zu Xine. Meldungen über andere Player werde ich einfach ignorieren und nicht komentieren.
Ich habe mich mit dem Entwickler vom Intel VAAPI Treiber in verbindung gesetzt und ihm die Probleme geschildert. Bin gespannt ob dort was rauskommt.
Hi Ebsi,
da habe ich mich wohl falsch ausgedrückt. Es ging mir nicht um den Vergleich mit dem VLC. Dass der das in Software mach ist klar, zumal ich das mit dem VLC unter Windows ausprobiert habe. Ich wollte nur für mich sicherstellen, dass das Deinterlacing in Xine nicht richtig funktioniert, indem ich das gleiche Material mal mit dem VLC und aktiviertem Software-Deinterlacing abspiele und mir den Unterschied anschaue. Meine Frage hier in die Runde sollte dann Aufschluss darüber bringen, ob ich bei mir irgendetwas falsch konfiguriert haben oder es ein generelles Problem ist. Deiner Antwort entnehme ich nun, dass es evtl. doch eher ein generelles Problem ist.
Grüße
Christoph
So ich habe gestern nach längerer Zeit mal wieder ein Update deiner xine-lib gemacht. Das läuft schon wirklich gut und stabil. Auch das Spulen in Aufnahmen (h.264 und MPEG2) funktioniert sehr gut. Lediglich das leidige Thema Deinterlacing; es funktioniert bei mir nachwievor nicht vernünftig (MPEG2). Es spielt keine Rolle, egal ob ich 0, 1 oder 2 einstelle, das Bild sieht immer gleich aus. Hast du eine Ahnung was ich falsch mache oder woran es liegt?
Ich hab mal zwei Testfiles (MPEG2) hochgeladen:
Laufschrift auf N24: http://rapidshare.com/files/454607295/00001.ts
Fussball im WDR: http://rapidshare.com/files/454610824/00001.new.ts
Edit:
Um es noch mal zu präzisieren: Das Deinterlacing scheint nicht zu funktionieren. Wenn ich die Aufnahmen beispielsweise im VLC Player öffne, sieht das Bild bei ausgeschaltetem Deinterlacing genauso aus wie xine + vaapi
Hat eigentlich noch mal jemand XBMC + VNSI/streamdev und VAAPI getestet? Ich habe mal gerade mit dem git von Lars Op den Kamp getestet, aber mit VNSI bekomme ich bei aktiviertem VAAPI einen segfault. Streamdev läuft einfach so nicht, obwohl es bei mir lokal im Netz gut funktioniert....
Zitat
Gracias, so läufts mit Bob flüssig. Ist vielleicht kein temporal/spatial aber akzeptabel.
ZitatOriginal von ebsi
Wen es intressiert der kann sich die Intel GPU tools installieren.
http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
Mit intel_gpu_top kann man sich die GPU auslastung ansehen.
cool, so etwas hatte ich schon gesucht, bringt nicht wirklich was, ist aber Interessant
Gibt es eigentlich für deinen vaapi Branch, public git oder svn Zugriff? Bei der vielen Änderungen im Moment. wäre das praktisch.
Mit dem aktuellen Entwicklungsstand bin ich echt zufrieden und meine Nvidia Karte kann jetzt einpacken.
Edit: Das mit Bob klappt doch noch nicht so ganz, wie gedacht. Wenn ich einen beliebigen SD-Kanal mal so ca. 5min laufen lassen, ruckelt es irgendwann wieder. Nicht ganz so schlimm wie ohne "tiling", aber doch sehr störend. (r162)
ZitatOriginal von ebsi
Update :
Habe die OSD handling logik überarbeitet, bassierend auf einem neuen VDPAU patch von der xine-devel ML. Unsclaed OSD's sollten nun in vdr-xine und xineliboutput funktionieren. Für vdr-xine muss ein workaround gemacht werden. Anbei das aktuelle Readme mit allen infos für die Konfiguraion.
Cool, Danke! Das probiere ich heute Abend mal aus.
Atechsystem
Was das Deinterlacing angeht, glaube ich schon eine leichte Verbesserung zu sehen, wenn ich "Top Field" wähle, aber die ist minimal. Bei "Bob" ruckelt es noch. Testen kann ich den Deinterlacer nur mit SD-Kanälen.
ZitatOriginal von Atechsystem
Kann ich bestätigen. Diesen hatte ich auch schon ein einziges Mal im laufenden Betrieb. Mit der alten xine ui kam er immer direkt beim Start (s.o.).
ZitatOriginal von Atechsystem
Das Deinterleacing über die VAAPI Option funktioniert bei mir nicht. Option 2 (Bob) führt lediglich zu einem Auffälligen Ruckeln.
Das kann ich bestätigen.
WAs genau meinst du mit OSD wird est spät angezeigt? Bei mir ist es so, dass beim Umschalten das OSD erst in der nativen Streamauflösung angezeigt wird und erst dann in der skalierten Auflösung. Ansonsten konnte ich keine OSD-Verzögerung feststellen.
Ah ok. Ich verstehe. Danke für die Erklärung!
Danke Wolfgang. Das hat geholfen!
ebsi
Das OSD sieht jetzt top aus. Wenn das mit xineliboutput laufen würde, wäre das die Ideallösung, denn da sind ja schon gute Software-Deinterlacer drin.
Beim Deinterlacer 2 in vdr-xine ruckelt bei mir das Bild. Die anderen beiden nicht, sind aber auch nicht besonders schön.
Danke erstmal, so ist vaapi jetzt auch im vdr wirklich nutzbar.
ZitatOriginal von ebsi
Man nehme das letze svn r150.
Verwende vdr-xine.
Unter den plugin Einstellung für vdr-xine stelle man "OSD Display mode" auf -> X11 overlay und betrachte das OSD.
Muss ich da etwas spezielles beachten? Wollte es mal testen. Habe das standard vdr-xine 0.9.3 und das xine-ui von wbreu genommen.
Stelle ich als Videoausgabe "vaapi" ein, so sehe ich wie der Treiber geladen wird, aber xine verabschiedet sich bereits beim Start mit
ZitatxiTK has received SIGSEGV signal, RIP.
Sehr cool, dass es mit der Entwicklung weiter geht. Danke ebsi!
Ich habe gerade auch mal die aktuelle xinelib getestet (r148). CPU-Last und Leistungsaufnahme sind phänomenal niedrig. HD und SD läuft bei ersten Tests ordentlich. Lediglich
# Priorität für Dekoder ffmpegaudio
# numeric, default: 0
engine.decoder_priorities.ffmpegaudio:1
führt bei mir dazu, dass ich keinen Ton habe... Ideen?
Hardware OSD ist bei HD und SD transparent und ruckelfrei, skaliert jedoch noch nicht korrekt.
ZitatOriginal von lokutus
Ich vermute mal, dass ich noch ein neueres FFMPEG brauche und xine gegen diese bauen muss.
Daran wird es vermutlich nicht liegen. Was gibt denn "vainfo" bei dir aus?
So, bei mir tut es jetzt auch mit compiz 0.9.2.1 und HUD und das Ganze auch ruckelfrei mit Singel Channel RAM. Das ist auf jeden Fall mal ein richtiger Fortschritt.
Ich habe aber noch mal ein paar Fragen bzgl. der Compiz-Konfiguration
1) Wenn ich OpenGL in Compiz nicht aktiviert habe, kann ich keine Fenster verschieben und das transparente HUD funktioniert nicht.
2) Wenn ich OpenGL in Compiz aktiviert habe, dann habe ich ein transparentes HUD und Fenster lassen sich verschieben, aber ich seltsame Grafikfehler beim Verschieben von Fenstern (nach rechts). Siehe angehängtes Bild.
Muss man beim Konfigurieren (mit ccsm) irgendetwas spezielles beachten? Gibt da ja nicht gerade wenige Optionen. Wie habt ihr das eingestellt (isbesondere wbreu)?
Wäre echt cool, wenn ihr mir da Feedback geben könntet. Wenn das hinhaut, widme ich mich anschließend den neuen xine-lib vaapi Versionen.
P.S. Als decorator habe ich den gtk-window-decorator angegeben.
Danke und Gruß
Christoph
Nachtrag: Also nachdem ich jetzt mal ein paar Tage abends intensiver SD-Fernsehen geschaut habe (Fussball), ist mir aufgefallen, dass das Bild auch mit Compiz 0.9.2.1 nicht flüssig läuft. Das Ruckeln ist aber ein anderes und geht glaube ich eher in die Richtung, die inob beschrieben hat. Interessanterweise läuft die Laufschrift aus meinem HD-Testfile flüssig, was meine Vermutung bestärkt, dass sich das Problem auf SD beschränkt. Ohne compisition läufts sauber und das Bild wirkt viel besser und homogener.
ja wie gesagt: Mit composite tut es bei mir auch noch nicht. Ich bin auch mit xineliboutput unterwegs.
Hast du bzgl. deiner Ruckler bei langsamen Kameraschwenks mal
gesetzt. Das führt bei mir dazu, dass ich
1) Keine Ruckler mehr habe und
2) keine Framedrops im log.
Ob diese Einstellung Nachteile hat weiß ich nicht.
Die von ebsi vorgeschlagene Kerneloption nohzf=off hat zwar einen ähnlichen Effekt, führt jedoch dazu, dass mein System im IDLE 37% mehr aus der Steckdose zieht (37 statt 27 Watt).
Obiges gilt für ein System mit einfachem Fenstermanager (derzeit fluxbox) und ohne HUD. Jetzt müsste es nur noch mit composite engine laufen....