Beiträge von ebsi

Intressante info wegen vaapi. Habe mal "libva-ext-vaapi" und "vaapi-ext-intel-driver" als PKGBUILD's für ArchVDR gemacht.

lg

ebsi

Zitat von kh1309

HI ebsi

git pull hat nichts gebracht.

Code

root@H67:~/tmp/xine-lib-vaapi# git pull --rebase
Current branch vaapi is up to date.

immer noch der gleiche Fehler.

Code

root@H67:~/tmp/xine-lib-vaapi# git show
commit 9dfc02242c2cedb14c058db39733760efbedfba1
Merge: b64758d e608145
Author: root 
Date:   Fri Jan 6 00:51:08 2012 +0100


    Merge branch 'vaapi-testing' of https://github.com/huceke/xine-lib-vaapi into vaapi

Noch ne Idee?
VG Kurt

Alles anzeigen

Auf welcher Distri compilierst Du ?

Zitat von kh1309

Hallole,
ich habe da ein Problem mit dem Compile von xine-lib-vaapi. Der make scheitert an po Files

Code

make[1]: Betrete Verzeichnis '/tmp/xine-lib-vaapi/po'
test ! -f ./libxine2.pot || \
          test -z "cs.gmo de.gmo en_US.gmo eo.gmo es.gmo eu.gmo fr.gmo it.gmo ja.gmo pl.gmo pt_BR.gmo sk.gmo tr.gmo" || make cs.gmo de.gmo en_US.gmo eo.gmo es.gmo eu.gmo fr.gmo it.gmo ja.gmo pl.gmo pt_BR.gmo sk.gmo tr.gmo
make[2]: Betrete Verzeichnis '/tmp/xine-lib-vaapi/po'
: --update cs.po libxine2.pot
rm -f cs.gmo && : -c --statistics -o cs.gmo cs.po
mv: Aufruf von stat für „t-cs.gmo“ nicht möglich: Datei oder Verzeichnis nicht gefunden
make[2]: *** [cs.gmo] Fehler 1
make[2]: Verlasse Verzeichnis '/tmp/xine-lib-vaapi/po'
make[1]: *** [stamp-po] Fehler 2
make[1]: Verlasse Verzeichnis '/tmp/xine-lib-vaapi/po'
make: *** [all-recursive] Fehler 1

Alles anzeigen

Was läuft da falsch?

Mach male ein "git pull --rebase" und probier es nochmal.

lg

ebsi

Zitat von decembersoul

ja habe ich auch gesehen.
Ist wohler eher für Firmen die Produkte auf der Basis vom PI Board anbieten wollen und gleich beim Start dabei sein wollen.
Sonst wäre es wohl ein Witz.

Da hat wohl einer keine Ahnung und ist zu faul auf http://www.raspberrypi.org/ nachzulesen was in dem Projekt passiert.

Auf http://www.raspberrypi.org/ lesen was es mit der eBay Versteigerung auf sich hat.

lg

Zitat von Copperhead

Da bist du aber nicht auf dem neusten Stand. VA-API ist auf weite Sicht tot. In die mesa-Treiber wird VDPAU eingebaut und VDPAU ist soweit ich mich erinnere ebenfalls Open-Source.

Die VDPAU Schnitstelle mag frei sein. Die dahinter liegenden Treiber sind es nicht. Da liegt der feine Unterschied.
Das VDPAU die Schnittstelle schlechthin wird glaub ich eher nicht. Wäre dem so, würden Intel und AMD es unterstützen. Intel verwehrt sich auch Gallium3D im mesa Stack. So wie ich es sehe werden VA-API, VDPAU und XVBA nebeneinander existieren.

Die traurige Wahrheit ist : http://xkcd.com/927/

Der Comic zeigt es gut. Und meine nun 20 Jährige Erfahrung im IT Business bestätigt es.

EDIT : Persönlich halte ich es für Schwachsinnig Video Decoding in Mesa zu verankern.

lg

ebsi

Zitat von johns

n

Zitat von johns

Danke,

Da steht bei mir auch ein dickes "FIXME: reordered" drin. Es ist immer gut, wenn jemand anderes drüber guckt.
Ich hatte danger.com auch gelesen, aber nicht mehr daran gedacht, daß ich ein eigenes get_buffer habe.

Edit:
Ändert aber nichts. H264 klappt, mpeg2 wildes springen, naja 3 Werte 160ms, 160ms, -200ms.

Johns

Alles anzeigen

Dann passt was deffinitiv nicht bei det pts kalkulation.

Zitat von johns

pkt_pts

Zitat von johns

Wenn die Libraries dies machen würden, dann würde ich dir recht geben.
"reordered_opaque" soll nicht mehr verwendet werden, dafür gibt es nun pkt_pts.
Ich hatte es getestet, es gibt die gleichen Schwankungen wie pkt_pts.
pkt_pts klappt bei H264 sehr gut mit ffmpeg, im Moment sind die Schwankungen nur noch bei mpeg. Vielleicht bekommen sie das auch noch in den Griff.

Also nehme ich jetzt immer den neusten Wert oder kleine Korrekturen in die Vergangenheit. Gibt sehr konstante montone PTS, die vielleicht einen festen Betrag falsch sind.

Die "Segmentation faults" treten nur bei libav auf, bei ffmpeg hatte ich diese vielleicht 1-2* beim Umschalten, bzw öfters im Audioteil.
Dekodieren und Anzeigen ist ein eigener gemeinsamer Thread und nur das OSD wird aber über Locks vom vdr Thread bedient.

Beim OSD habe ich genau den umgekehrten Weg festgestellt, wenn ich genau 1* "vaAssociateSubpicture" nach dem Erstellen der Surfaces mache, dann vergisst Intel die Position und Skalierung.

Ja VA-API ist sehr kritisch ein vaSync zuviel oder zuwenig und es knallt.
Und regelmässig hängt sich die komplette GPU auf und entweder geht gar kein VA-API mehr oder es zeigt nur noch schwarze Bilder oder mach keine V-Syncs mehr.

Die meisten testen den vdpau-driver, mit dem Teste ich auch. Nur wenn es eine neue Version gibt, teste ich den Inteltreiber, dann das neuste was gentoo hat.

Johns

Alles anzeigen

Leider verwendest das plugin pkt_pts auch nicht. In der Codec_get_buffer Funktion fehlt :

ffmpeg neu :

frame->pkt_pts = avctx->pkt->pts;

alte ffmpeg :

frame->reordered_opaque = avctx->reordered_opaque;

Ohne dem wirst du kein reordering im decoder mitbekommen und die PTS werte laufen falsch.

In diesem Tutorial wird das mit dem dts/pts handling gut beschrieben : http://dranger.com/ffmpeg/

Auch im ffmpeg source sieht man das dts/pts handling schön. ffmpeg.c glaub ich.

lg

ebsi

Zitat von fnu

ebsi

Coole Tips, aber ein Hinweis, die zitierte Antwort zielte auf "libav", also den ffmpeg Fork, ab und nicht wie evtl. interpretiert "libva" also VA-API. Ist ein sch... Wortspiel, ich weiß schon ...

Aber noch ein Feedback von mir, egal ob jetzt die Video-Frame korrekt behandelt werden oder VA-API Thread save ist. Das VA-API Bild ist wie ich es gesehen habe, nicht gut. Wäre das das erste was ich in HD Bereich gesehen hätte wäre das bestimmt ok gewesen, aber VDPAU hat mich/uns verwöhnt, von daher ist das eben jetzt der Maßstab. VA-API ist da soweit ich das sehe, leider weit weg ...

Regards
fnu

Alles anzeigen

Mir ist die Diskussion besseres Bild oder nicht egal. Hab es eh schon ein paar mal erklärt, das meiner einer bei 3-4m Entfernung zum 47" das nicht so unterscheiden kann. Was mich aber extrem an VDPAU gestört hat, sind die decoding Hänger im Nvidia Treiber, die wie man im Board lesen kann, bis heute nicht wirklich behoben sind. Das war der Grund warum ich mir VA-API angetan habe und auch dabei bleiben werde. Schicker Vorteil bei VA-API, eine Quelloffene alternative zu Nvidia. Das mit der Bildqualität wird bei VA-API auch besser werden, wenn ich die Commitmeldungen im freedesktop git richtig interpretiere.

lg

ebsi

Zitat von johns

Also die Ergebnisse hängen mit der libav Version zusammen:

0.7.2: avcodec_open2 fehlt
0.7.9999 Segmentation fault in ff_put_pixels_clamped_mmx
0.8_pre20111116 Segmentation fault + hangups
git von jetzt hat zumindest 10 Minuten Test mit Umschalten überlebt, aber die Zeitstempel schwanken hier immer noch sehr start.

Bist du sicher das du libav 0.7.2 hast?
Johns

Alles anzeigen

Was mir bis jetzt im plugin aufgefallen ist :

Von meiner sicht der Dinge ist dein dts/pts handling für vaapi falsch. Du must das Reordering der Frames berücksichtigen "reordered_opaque" . Die Frames müssen nicht zwangsweise geordnet codiert sein. Wenn dem nicht so ist, macht der Decoder ein Reordering der Frames was in deiner Logik zwangsweise zu falschen pts werten führen muss.

Treten Segmentation faults bei vaapi bei der reinen decodierung auf, spricht ohne aktivem OSD oder Deinterlacing, ist es 100% sicher das seitens der Applikation nicht sichergestellt wurde das das Surface vom decoder frei gegeben wurde. Erst nach freigabe des Surfaces darf es zur Anzeige verwendet werden.

Achte bei VAAPI immer darauf das es zu keiner doppelten Verwendung von Surfaces kommt. VAAPI ist nicht wirklich Thread save. Auch beim OSD vaAssociateSubpicture/vaDeassociateSubpicture jeweils nur einmal aufrufen. VAAPI verzeiht keine Logik fehler/glitches. Da wird man meistens mit einem Segmentation fault oder den "GPU hangs" bestraft.

Der stabilste Intel Treiber für vaapi ist : xf86-video-intel-2.15.0. Mit späteren Versionen kommt es vermehrt zu den "GPU hangs".

Zitat von googles

Opengl hat aber mit der video decodierung nichts zu tun. Oder wozu brauchen wir dann vdpau?

OpenGL hat nicht viel mit OpenGL ES 2.0 gemeinsam. Da müsste schon ein neues OpenGL ES 2.0 für xine her.

Zitat von johns

Abend,

Habe bei meinen Plugin herausgefunden, das nun das Intel Backend unskaliertes OSD unterstüzt.
In der Anleitung "VA_SUBPICTURE_DESTINATION_IS_SCREEN_COORD" suchen.

Mal als Tipp zum einbauen, damit wäre wieder ein Punkt der an va-api nervt weniger.

Johns

Alles anzeigen

Leider wird es nicht von allen VAAPI Implemntierungen unterstützt. Somit ist das Interesse dies einzubauen sehr gering.

lg

ebsi

Intel Celeron Single-Core G440 ist auch ne nette CPU fürn vdr.

http://ark.intel.com/products/…-G440-(1M-Cache-1_60-GHz)

lg

ebsi

Zitat von johns

[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

Habs mal ins git übernommen. Finde es schade das die Intel Treiber nicht so stabil sind.

Sollte jemand die Muse finden VAAPI für xine-lib-1.2 und ATI zu fixen, nehme ich den/die patches gerne in mein git repo auf.

lg

ebsi

Zitat von hueb_s

johns: Hast du das mit yavdr bzw. Ubuntu getestet?

HDTV (h.264) funktioniert bei mir (AMD E-350) per streamdev-server an VLC völlig problemlos:
- aktuelles Oneiric - VAAPI-enabled VLC ist schon dabei...
- FGLRX 11.10 - oneiric .debs selbst gebaut
- libva von ppa:ubuntu-x-swat/x-updates
- ffmpeg/libav von ppa:motumedia/libav-daily
- mplayer-vaapi von ppa:sander-vangrieken/vaapi

Nur die libxine (GIT vaapi-testing von https://github.com/huceke/xine-lib-vaapi) bekomme ich nicht stabil zum laufen.
Entweder kommen Abbrüche direkt nach dem Start oder das Bild flackert extem - suche noch die Ursache...x

Alles anzeigen

Zitat von iNOB

Soweit mit bekannt hat ebsi die vaapi für xine lediglich für INTEL und nicht für ATI angepasst. Deshalb braucht man sich nicht wundern, wenn das mit ATI nicht funktioniert.

Gruß
iNOB

Habe auch mit ATI experimentiert. Kann nur sagen deren Treiber sind der letzte dreck. Mit INTEL läuft es ganz gut.

lg

ebsi

Zitat von Flachzange

stimmt..hatte ich ja gerade letzte Woche selbst noch hier gelesen...blödes Kurzeitgedächtnis...*schäm*

Ich probiere es mal aus. Danke!

Edit: Scheint zu funktionieren...komisch

Ach ja, das Kurzzeitgedächtnis. Funktioniert bei mir auch prima

lg

ebsi

Zitat von Flachzange

nabend, ich hatte mich nach der Update-Orgie in der letzten Wochen gewundert, warum die Umschaltzeiten recht hoch waren und xine beim Umschalten mit einer sehr hohen Wahrscheinlichkeit (> 50%) freezed. Heute hab ich dann mal rumgespielt und video.output.vaapi_guarded_render:0 gesetzt. Damit läufts ordentlich, keine Freezes und schnelles Umschalten. Gibt es irgendwelche Bedinungen (Treiber, Kernel, etc) damit es auch mit der guarded Render Methode läuft?

Hi,

das hört sich noch dem libxcb Problem an. Ich musste libxcb patchen.

https://archvdr.svn.sourceforg…/xcb_wait_for_reply.patch

lg

ebsi

Zitat von OppTupacShakur

hi, ich hab da mal eine kurze frage.
gibt es gen_vaapi_patch.sh nun gar nicht mehr? habe damit immer den patch erzeugt um es in df-osd-handling+alter-vdpau-h264-decoder git einzubasteln, für mein debian paket.

"git diff master vaapi-testing" macht den Trick.

lg

ebsi

Die xine-lib VAAPI Entwicklung hat eine neues zu Hause auf github bekommen.

Um an die Source zu kommen :

git clone git://github.com/huceke/xine-lib-vaapi.git
cd xine-lib-vaapi
git checkout vaapi-testing

ffmpeg muss in der aktuellen git Version verwendet werden oder folgender commit gegen Version 0.7/0.8 angewandt werden :

http://git.videolan.org/?p=ffm…5aae9f0baa47671af15de181a

Libxcb hat ein deadlock Problem welches im libxcb git behoben wurde oder folgenden Patch gegen libxcb 1.7 anwenden :

https://archvdr.svn.sourceforg…/xcb_wait_for_reply.patch

Es gibt auch ein rudimentäres README dazu :

https://github.com/huceke/xine…aapi-testing/README.vaapi

Oder einfach hier im Forum diesen Thread durchlesen :

http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/102819-hd-vdr-mit-intel-hd-graphics-testbericht-zu-vaapi/

lg

ebsi