Nicht ganz korrekt. Der master Tree weist diese API Änderung nicht nicht auf.
Posts by ebsi
-
-
Leider wird sich xine nicht so leicht auf den Raspberry PI portieren lassen.
Mal grundsätzliches. Am PI wird OpenMAX für die Video/Audio decodireung/ausgabe verwendet und GLES fürs Rendering.
In OpenMAX wird eine Kette mit OpenMAX Komponenten für die Bearbeitung der Daten aufgebaut. Dies kann eine reine Decodierung von Audio/Video sein, oder eine komplette Kette bis zur Ausgabe bilden. Für die Synchronisierung von Audio/Video verwendet OpenMAX eine eigene Clock welche unter den Komponenten geshared ist.
Prinzipiell könnte man nur das reine Decodieren am PI verwenden, die Daten aus dem Decoder holen und dann mit GLES rendern. Leider geht das aus Performance gründen nicht. Somit lässt man OpenMAX alles erledigen.
Zum Rendering stehen mehrere Planes zur Verfügung. Wenn man OpenMAX bis zur Ausgabe verwendet, kommen zwei Planes ins spiel :
Plane 1.) Videoausgabe durch die OpenMAX Komponente.
Plane 2.) GLES rendering des OSD.In xine lässt sich das ganze nun nicht so einfach implementieren. Der Teil zum rendern des OSD ist noch der simple Teil. Die Integration der OpenMAX Komponenten wird schon etwas schwieriger. Die gemeinsam benutze Clock in OpenMAX wird zum eigentlichen Problem. in xine ist es nicht so einfach Daten zwischen dem Video und Audio Decoder zu teilen. Das musste ich schon leidvoll bei der VAAPI implementierung für xine feststellen.
Warum ich nun das ganze weiß ist ganz einfach. Zum einen habe ich schon Erfahrungen mit xine gesammelt ( VAAPI ), zum anderen habe ich den XBMC Port auf den PI ( plus omxplayer ) gemacht.
Der wirklich gangbare weg für den PI ist eine eigenständiges VDR Frontend. Das softhddevice ist ein interessanter Ansatz dem leider eine Trennung in Client/Server fehlt. Was es schon von vorne herein für einen stabilen VDR betrieb disqualifiziert ( meine Persönliche Meinung ).
lg
ebsi
-
Wurde denn schon ein XBMC (+PVR) oder ein VDR auf dem Board zum Laufen gebracht?
-
Im Moment ist absolut nicht klar welchen branch man bei VA-API nehmen. Ein paar fixes in dem branch ein paar in einem anderen. Die Entwicklung sieht dort sehr planlos aus.
-
Lösche auch die Header Files. /usr/include/va oder /usr/local/include/va
lg
ebsi
-
Im libva git git es einen neuen staging tree. In va/va_vpp.h steht beschrieben wie die neuen Processing API zu benutzen ist.
Wie ich das verstehe, sollte das auch auf Surfaces nach dem Decoding funktionieren. Was uns gute Chancen einräumen würde die neuen Deinterlacer zu benutzen.
johns: was meinst du dazu ?
-
wie man wohl hier sehen kann.Aber - wie gesagt - auch auf sandy bridge ist xine trotz funktionerendem Deinterlacer für mich kaum zu gebrauchen. Bei beim Kanalwechsel gibt es einen Deadlock (vermutllich im Treiber) und es hängt bis zum nächsten UI Event. Für Ivy Bridge würde ich erst mal nicht mehr erwarten. Die Architektur ist da ja die gleiche.
VG Kurtverwendest du vdr-xine oder xinelibouput ? Noch ein heisser tip, libxcb 1.8 verwenden. Version 1.7 hatte probleme mit deadlocks.
lg
ebsi
-
ebsi: Hast du den Kernel auch schon gebaut und ein Interlaced Modus getestet? Vielleicht habe ich da etwas falsch gemacht.
Kann sein das ich am Wochenende zeit habe es zu testen.
lg
ebsi
-
Eine xorg.conf mit den Modelines wär net schlecht
-
So habe die Ganze Sache zu Ende analysiert. Der Patch bekämpft nur die Symtome und nicht die Ursache.
Also es gibt Fernsehsender (z.b. Nick/CC) die schicken mehrere Bilder in einem Packet.
Diese Packet übergebe ich so an ffmpeg. ffmpeg erkennt aber bei VAAPI und wahrscheinlich
auch VDPAU nicht, daß ein neues Bild kommt. Für Software Decoder ist etwas vorhanden.
Dadurch erzeugt der VAAPI Teil von ffmpeg Buffer die nicht verwendet werden und in den
Speicher gemappt werden. Alle erzeugten Slice Buffer werden dann an libva übergeben,
was dann bei dem nächsten Aufruf von vaPutSurface mit "GPU hung" quittiert wird.Meine Ursache habe ich nun überarbeitet. xine-lib scheint hier mit einer anderen Logic zuarbeiten
und ist vermutlich nicht betroffen. Beim Rest weiss ich nicht ob es echte Fehler sind.Johns
Kann schon sein das xine-lib auch davon betroffen ist. Kannst Du einen testclip erstellen und verfügbar machen ? Würd das gerne mit dem xine mpeg2 parser mal checken.
-
Ich habe einen Bug in ffmpeg gefunden, der wahrscheinlich die Ursache für die GPU hung sind.
Es könnte auch sein, daß es noch einen weiteren in libav auslöst.ffmpeg erzeugt und mapped VA-API Buffers mehrmals und gibt die erst sehr spät frei. Dies passiert bei kaputten Frames.
Leider gibt es nun grüne Artefakte beim Umschalten bei Nick/CC und SIXX, ...
Johns
Hast Du den patch an ffmpeg / libva gemeldet ? Gwenole ist glaub ich der richtige den man ansprechen sollte.
lg
ebsi
-
Da haben die ffmpeg Entwickler aufgeräumt. Das war schon länger als deprecated markiert.
Hab einen workaroud in den vaapi-testing tree gepusht.
-
ich wollte gerade deine xine-lib gegen ein aktuelles ffmpeg(git von heute) bauen und bekomme einen unerwarteten Fehler:
Code
Display MoreCC xineplug_decode_ff_la-ff_video_decoder.lo ff_video_decoder.c:135:3: error: unknown type name 'AVPaletteControl' ff_video_decoder.c: In function 'get_buffer': ff_video_decoder.c:183:13: error: 'AVFrame' has no member named 'age' ff_video_decoder.c:286:11: error: 'AVFrame' has no member named 'age' ff_video_decoder.c: In function 'ff_handle_special_buffer': ff_video_decoder.c:1194:5: error: unknown type name 'AVPaletteControl' ff_video_decoder.c:1197:18: error: 'AVCodecContext' has no member named 'palctrl' ff_video_decoder.c:1198:24: error: 'AVPaletteControl' undeclared (first use in this function) ff_video_decoder.c:1198:24: note: each undeclared identifier is reported only once for each function it appears in ff_video_decoder.c:1198:42: error: expected expression before ')' token ff_video_decoder.c:1202:22: error: request for member 'palette' in something not a structure or union ff_video_decoder.c:1207:20: error: request for member 'palette_changed' in something not a structure or union ff_video_decoder.c: In function 'ff_video_open_plugin': ff_video_decoder.c:2023:16: error: 'AVCodecContext' has no member named 'palctrl'
Hast du eine Idee, was da los ist?
Da haben die ffmpeg Entwickler aufgeräumt. Das war schon länger als deprecated markiert.
-
video.processing.vaapi_mpeg_softdec:0
video.processing.vaapi_mpeg_softdec_deinterlace:0Ich hatte mit mpeg1/2 Hardware Decoding das Problem das sich die Maschine komplett aufgehängt hat. Kann nicht sagen ob das nun in den VA-API treibern beseitigt wurde. Und auf den Clarkdale CPU's gab/gibt es auch kein Hardware deinterlacing für mpeg1/2. Das konnte nur der SandyBridge VA-API support.
Der erste Wert deaktiviert VA-API für mpeg1/2. Sollte er auf 1 sein wird Software Decoding für mpeg1/2 verwendet. Der zweite Wert baut auf dem ersten auf. Wenn Software mpeg1/2 verwendet wird kann zusätzlich ein einfacher Deinterlacer im ffmpeg aktiviert werden.
lg
ebsi
-
xine: i965_drv_video.c:2072: i965_check_alloc_surface_bo: Zusicherung obj_surface->fourcc == fourcc nicht erfüllt.
Hast du vielleicht eine Idee, was das sein könnte?
Welche xf86-video-intel verwendest Du ? Auf den Clarkdale CPU's habe ich die besten Ergebnisse mit dem xf86-video-intel-2.15.0 gemacht. Wenn ich es Deiner Signatur richtig entnehme verwendest Du solch eine CPU.
lg
ebsi
-
Zitat von »kh1309«
Monitor mit 1680x1050@50HZZitat von »kh1309«
HD1080i hat Probleme bei hoher Auflösung (1920x1080).Wie ist CPU Auslastung ? Sollte die hoch sein ist das ein Indiz dafür das das Hardware Decoding nicht aktiv ist.
lg
ebsi
-
Was ist gpu top? Bzw woher hast Du das?intel_gpu_tools : http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
lg
ebsi
-
Zwei wichtige Grundeinstellungen für xine :
Quoteengine.decoder_priorities.ffmpegvideo:1
Muss gesetzt sein sonst verwendet xine den libmpeg2 decoder für mpeg1/2. Das funktioniert nicht mit VA-API.
Quotevideo.processing.ffmpeg_enable_vaapi:0
Dies deaktiviert das Hardware Video decoding.
Quotevideo.processing.ffmpeg_enable_vaapi:1
Dies aktiviert das Hardware Video decoding. Ist eigentlich der default Wert.
lg
ebsi
-
Bitte mach am freedesktop Bug Tracker Reports dazu auf und sendet es auch an die libva Mailingliste :
Informationen zur ML findet ihr hier : http://freedesktop.org/wiki/Software/vaapi
lg
ebsi
-
In den vaapi-testing tree übernommen.