Posts by ebsi

Quote from johns

VA-API GIT hat eine neue API:

Code

#ifndef VA_SURFACE_ATTRIB_SETTABLE
/// make source compatible with old libva
#define vaCreateSurfaces(d, f, w, h, s, ns, a, na) \
    vaCreateSurfaces(d, w, h, f, ns, s)
#endif

und alle vaCreateSurfaces ändern auf neue API.

Johns

Display More

Nicht ganz korrekt. Der master Tree weist diese API Änderung nicht nicht auf.

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

Quote from Cybso

Wurde denn schon ein XBMC (+PVR) oder ein VDR auf dem Board zum Laufen gebracht?

https://github.com/xbmc/xbmc-rbp

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 ?

Quote from kh1309

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 Kurt

verwendest du vdr-xine oder xinelibouput ? Noch ein heisser tip, libxcb 1.8 verwenden. Version 1.7 hatte probleme mit deadlocks.

lg

ebsi

Quote from Atechsystem

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

Quote from johns

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

Display More

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.

Quote from johns

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

Display More

Hast Du den patch an ffmpeg / libva gemeldet ? Gwenole ist glaub ich der richtige den man ansprechen sollte.

lg

ebsi

Quote from 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.

Quote from Flachzange

ebsi

ich wollte gerade deine xine-lib gegen ein aktuelles ffmpeg(git von heute) bauen und bekomme einen unerwarteten Fehler:

Code

CC     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'

Display More

Hast du eine Idee, was da los ist?

Display More

Da haben die ffmpeg Entwickler aufgeräumt. Das war schon länger als deprecated markiert.

Quote from kh1309

video.processing.vaapi_mpeg_softdec:0
video.processing.vaapi_mpeg_softdec_deinterlace:0

Ich 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

Quote from Flachzange

xine: i965_drv_video.c:2072: i965_check_alloc_surface_bo: Zusicherung obj_surface->fourcc == fourcc nicht erfüllt.

Quote from Flachzange

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

Quote from fnu

Zitat von »kh1309«

Monitor mit 1680x1050@50HZ

Quote from fnu

Zitat 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

Quote from Torsten73

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 :

Quote

engine.decoder_priorities.ffmpegvideo:1

Muss gesetzt sein sonst verwendet xine den libmpeg2 decoder für mpeg1/2. Das funktioniert nicht mit VA-API.

Quote

video.processing.ffmpeg_enable_vaapi:0

Dies deaktiviert das Hardware Video decoding.

Quote

video.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.