News Mesa 10.0 mit Unterstützung für OpenGL 3.3

[fethomm]

Am Wochenende gab Entwickler Ian Romanick in einer knapp gehaltenen E-Mail die sofortige Verfügbarkeit der freien Grafikbibliothek Mesa 3D in Version 10.0 bekannt. Die neue Version integriert OpenGL 3.3 sowie GLGS 3.30 und erhöht die Geschwindigkeit der Bibliothek insgesamt.

Zur News: Mesa 10.0 mit Unterstützung für OpenGL 3.3

 

[Krautmaster]

Wie stehts denn um das Vaapi Deinterlacing?

 

[Zehkul]

Das letzte, was ich gehört habe, war, dass Vaapi immer noch und generell stinkt. Ich bin froh, dass ich mit AMD Hardware VDPAU nutzen kann. Ich hatte überall nur Probleme mit Vaapi, und warum willst du überhaupt Hardwaredecoding? Software reicht doch für alles, und OpenGL output läuft mit freien Treibern zumindest auch richtig flüssig und gut.

Mesa 10 wird schon lustig, (läuft damit dann eigentlich natural selection 2?) hoffe dass das bald in Arch landet.

 

[ghecko]

VAAPI läuft mitunter ganz hervorragend auf Intel Hardware. War selbst überrascht. die Implementierung in den mpv nagt zwar noch etwas mehr an der CPU als die vaapi-Mplayer Variante, dafür aber rockstable. Und die Bildqualität kann sich auch sehen lassen. Zumindest auf einer HD4000.
Bei AMD-Karten hatte ich allerdings generell Probleme mit VAAPI, und davor mit Xbva. Hier ist VDPAU wirklich ein Fortschritt, zumal es die populärste und stabilste hwdec API darstellt und daher von den meisten Playern unterstützt wird.

 

[NemesisFS]

Im AUR gibt es schon die aktuelle Version, als upstream clone, wenn man es eilig hat =)

Wäre schön, wenn auch die älteren Intel Treiber OpenGL >= 2.1 unterstützen würden...

 

[Stebs]

VAAPI läuft mitunter ganz hervorragend auf Intel Hardware. War selbst überrascht. die Implementierung in den mpv nagt zwar noch etwas mehr an der CPU als die vaapi-Mplayer Variante, dafür aber rockstable. ..

Es gibt aber leider für MPV noch kein funktionsfähiges GUI (CMPlayer war nicht wirklich benutzbar), habs jetzt gerade doch mal wieder installiert, hmm ok, scheint deutlich besser geworden zu sein seit meinem letzten Versuch.
Das OSD ist jetzt nicht soo so schlecht, es fehlen mir aber trotzdem noch weitere Funktionen einer normalen GUI.
Bisschen rumexperimentiert und wenn man die beiden Zeilen hwdec=vaapi und vo=vaapi in die /.mpv/config Datei einfügt, dann erst scheint vaapi wirklich benutzt zu werden, CPU-Auslastung geht auf quasi auf 0 runter (so wie man es von vdpau gewohnt ist), hui, schonmal nicht schlecht.

SMplayer mit vaapi-mpayer brauch erstaunlicherweise merkbar mehr CPU als VLC (mit aktiviertem vaapi), unter anderem sollte man drauf achten "Threads zur Dekodierung" auf 1 zu lassen, sonst gehts gar nicht.
VLC hat aber auch ärgerliche Bugs (öfters Artefakte mit vaapi und automatisches laden von Untertiteln kann zu minutenlangen Wartezeiten führen).

Gstreamer-vaapi ist noch CPU-intensiver als die anderen.
Alles mit HD4000 getestet.

Dagegen ist VDPAU auch auf uralt Geforces eine reine Wohltat z.B. mit SMPlayer: absolut minimalste CPU-Auslastung (tendiert gegen 0) und einwandfreies Bild.
Vaapi funktioniert prinzipiell also schon, aber bei weitem nicht so problemlos wie von vdpau gewohnt.

Das neueste MPV scheint momentan der einzigste Player zu sein der vaapi richtig ausnützen kann, hoffentlich gibts dafür in Zukunft auch Frontends...

Update:
Hab nun die Einstellungen fuer MPV (version 0.2.3-2) angepasst, so wird er erstmal mein Defaultplayer
Falls jemand interessiert ist;

die Datei config:

hwdec=vaapi
vo=vaapi
fs=yes
slang=de
alang=de,en
stop-screensaver="yes"

# allow to seek in a file which is still downloading whilst watching it
idx=yes

# don't allow a new window to have a size larger than 90% of the screen size
autofit-larger=90%x90%

# add black borders so the movies have the same aspect ratio of the monitor
# for wide screen monitors
vf=expand=::::1:16/9:16

# execute a command every 30 seconds
# useful to disable a non-standard-compliant screensavers and to work around buggy behaviours
# BE WARNED: to avoid dangerous commands is your responsibility
#heartbeat-cmd="xscreensaver-command -deactivate &" # stop xscreensaver

und input.conf:

MOUSE_BTN0 cycle pause
MOUSE_BTN0_DBL cycle fullscreen # toggle fullscreen on/off
MOUSE_BTN1 cycle mute
MOUSE_BTN2 frame_step 
MOUSE_BTN3 add volume 1
MOUSE_BTN4 add volume -1
MOUSE_BTN5 seek -10
MOUSE_BTN6 seek 10

 

[Krautmaster]

Das letzte, was ich gehört habe, war, dass Vaapi immer noch und generell stinkt. Ich bin froh, dass ich mit AMD Hardware VDPAU nutzen kann. Ich hatte überall nur Probleme mit Vaapi, und warum willst du überhaupt Hardwaredecoding? Software reicht doch für alles, und OpenGL output läuft mit freien Treibern zumindest auch richtig flüssig und gut.

naja ZB BayTrail als HTPC Plattform, wenn du keinen Quad verbaust kanns je nach HD Material mit CPU Decoding in SW schon eng werden, vor allem wenn dann bei LiveTv noch Deinterlacing dazu kommt...

Das recht junge AMD VPDAU rennt übrigens ganz gut. Fehlen noch ein paar Deinterlacing Implementierungen und 4K

 

[Zehkul]

Man sollte sich aber, wenn man zukunftssicher sein will, gar nicht auf Hardwaredecoding verlassen. Na ja,hängt wohl auch vom Anwendungsgebiet ab. Springt ja nicht jeder immer sofort auf den neuesten Codec.
Ich verwende trotz freier Treiber eher kein VDPAU. Ich schaue die meiste Zeit Videos, die gar nicht hardware dekodierbar sind, und VDPAU rendert Untertitel ein gutes Stück langsamer als Opengl, warum auch immer. Das wird aber, fällt mir gerade auf, das erste sein, was ich mit Mesa 10 dann testen werde. (Ach ja, „Untertitel“, die die CPU komplett auslasten)

Das neueste MPV scheint momentan der einzigste Player zu sein der vaapi richtig ausnützen kann, hoffentlich gibts dafür in Zukunft auch Frontends...

Gibt scheinbar nen neuen Versuch. Vielleicht wird’s diesmal was.
https://github.com/sebadoom/mpvguihs

Ich finde aber gerade mit OSC ein Frontend weniger wichtig, alle simplen Funktionen sind doch damit gut mit der Maus bedienbar.

VAAPI läuft mitunter ganz hervorragend auf Intel Hardware.

Wie sieht es mit dem VAAPI Backend für VDPAU aus? Das hatte ich mit fglrx mal eingerichtet. Wrapperhölle, VDPAU über VAAPI über xvba. War absolut scheußlich, könnte aber mit Intel und ohne xvba Mist deutlich besser funktionieren.

Übrigens sollte sich der OpenGL Output von Mpv mittlerweile mit jedem Hardwaredecoding kombinieren lassen, aber ich glaube nicht, dass das bei Vaapi viel bringt.


@Stebs: Ich empfehle noch die Option:
demuxer-mkv-subtitle-preroll
Für Untertitel eigentlich fast schon ein Muss.

 

[Stebs]

Man sollte sich aber, wenn man zukunftssicher sein will, gar nicht auf Hardwaredecoding verlassen. Na ja,hängt wohl auch vom Anwendungsgebiet ab. Springt ja nicht jeder immer sofort auf den neuesten Codec.
Ich verwende trotz freier Treiber eher kein VDPAU. Ich schaue die meiste Zeit Videos, die gar nicht hardware dekodierbar sind, und VDPAU rendert Untertitel ein gutes Stück langsamer als Opengl, warum auch immer. Das wird aber, fällt mir gerade auf, das erste sein, was ich mit Mesa 10 dann testen werde. (Ach ja, „Untertitel“, die die CPU komplett auslasten)

Im Endeffekt ist Hardwaredecoding ja "nur" ein "Bonus" der dafuer sorgt dass mein Netbook den Luefter nicht anschmeissen muss und so Nachts den leisen Filmgenuss stört und vorallem den Akku deutlich weniger schnell leer saugt.
Hab vorhin auch mal ein Hi10P Testfile mit ASS Untertitel ausprobiert (nehme an du hast von solchen Files geredet), lief einwandfrei, nur war die CPU-Last eben nicht 0-2% sondern 10-15% (vergleichbar mit Softwaredecoding von anderen normalen Files). Der ASS Untertitel verursachte keine merkbare Last. Das scheint eh nur ein Problem des recht neuen VDPAU-Modus vom Radeon Treiber zu sein (rsp. evtl. ein damit neu entdecktes Problem in Mesa), neuere Mesa-Versionen sollen zumindest etwas besser sein (gibt dazu Diskussionen auf der mpv-Seite). Der Intel-Treiber+ VAAPI scheinen da kein Problem zu haben.

Gibt scheinbar nen neuen Versuch. Vielleicht wird’s diesmal was.
https://github.com/sebadoom/mpvguihs

Ich finde aber gerade mit OSC ein Frontend weniger wichtig, alle simplen Funktionen sind doch damit gut mit der Maus bedienbar.

Dieses simple GUI bringt mir momentan nichts, momentan wird aber eh an einer neuen Schnittstelle zwischen Frontend und mpv gearbeitet.
Das OSC ist tatsaechlich recht brauchbar, trotzdem fehlen mir (auf lange Sicht) Sachen wie nachträgliches laden von/browsen nach Untertiteln, Info über Metadaten/Codec etc.

Wie sieht es mit dem VAAPI Backend für VDPAU aus?

Hatte ich früher mal probiert, aber war definitiv nicht besser als reines vaapi. Und momentan scheint VAAPI mit Ivy-Bridge auf mpv ja kolossal zu laufen: 0-2 % gesamte Systemauslastung eines i5-3317U für einen anspruchsvollen 1080p AVC Film mit offenem Browser und Steam im Hintergrund, dabei einwandfreie Bildqualität, was will man mehr...
OpenGL Output kann da dann auch nicht mehr bringen.

@Stebs: Ich empfehle noch die Option:
demuxer-mkv-subtitle-preroll
Für Untertitel eigentlich fast schon ein Muss.

Danke, habs mir angeschaut aber muss erstmal testen ob man das damit langsamere suchen negativ merkt. Im Endeffekt nutze ich eh selten Untertitel, höchstens wenn fiese englische Dialekte mich auf Dauer dann doch schlauchen.

 

[Zehkul]

Der ASS Untertitel verursachte keine merkbare Last.

Hehe dann hast du nur noch keine Datei abgespielt, die tatsächlich fordernd ist. Selbst xyvsfilter, der ja doch noch ein gutes Stück optimierter und daher schneller rendert als Libass, wird auf zu schwachen PCs von manchen Sachen einfach in die Knie gezwungen. (Commie häufig, anime koi Karaoke bei den letzten Projekten, Underwater ist auch extrem viel in letzter Zeit, und natürlich irrational typesetting wizardry)

Das ASS Format wurde in den letzten 2 Jahren zunehmend als eine ineffiziente Renderbibliothek für Effekte aller Art missbraucht. Untertitel sind das eigentlich keine mehr. Vielleicht mach ich später noch mal ein Gif von was, sieht schon teils ziemlich cool aus.

Dieses simple GUI bringt mir momentan nichts, momentan wird aber eh an einer neuen Schnittstelle zwischen Frontend und mpv gearbeitet.

Ja, ist ja auch extrem neu. Sieht aber fast so aus, als ob es diesmal klappen könnte. Dieses „Momentan“ ist witzig, momentan seit einem halben Jahr, in dem genau überhaupt nichts passiert ist. (Es taucht öfters jemand für ein GUI auf, bisher sind aber alle in irgendeiner Versenkung verschwunden *g*)

 

[Stebs]

Hehe dann hast du nur noch keine Datei abgespielt, die tatsächlich fordernd ist.

Das mag natürlich sein, hast du evtl. eine url, wenn möglich eher eine kürzere Sequenz?

Dieses „Momentan“ ist witzig, momentan seit einem halben Jahr, in dem genau überhaupt nichts passiert ist. (Es taucht öfters jemand für ein GUI auf, bisher sind aber alle in irgendeiner Versenkung verschwunden *g*)

Seit 2 Tagen reden sie aber wieder konkreter darüber: https://github.com/mpv-player/mpv/issues/252

 

[ghecko]

Wie sieht es mit dem VAAPI Backend für VDPAU aus? Das hatte ich mit fglrx mal eingerichtet. Wrapperhölle, VDPAU über VAAPI über xvba. War absolut scheußlich, könnte aber mit Intel und ohne xvba Mist deutlich besser funktionieren.

Da hab ich lange nichts mehr von gehört. Grundsätzlich deswegen, weil VAAPI standalone immer besser lief als über einen VDPAU-wrapper, soweit sich ein developer dazu erbarmt hat, es zu implementieren.

Übrigens sollte sich der OpenGL Output von Mpv mittlerweile mit jedem Hardwaredecoding kombinieren lassen, aber ich glaube nicht, dass das bei Vaapi viel bringt.

Da irrst du dich. Folgende Datei:
[ChiWorks][Coalgirls]_Eden_of_the_East_OP_1920x1080@60_Blu-Ray_FLAC[a20e53f7].mkv (such mich auf nyaa)
Das ist eine der anspruchsvollsten Dateien die ich besitze. Endlos viele Vectoren, 60 Bilder die Sekunde, und das in 1080p.
Auf meinem Desktop beschäftigt die durch Softwaredecoding einen i5-2500k durchschnittlich zu 35%.
Auf dem Lenovo E130 mit 1,8Ghz Ivy Bridge Dualcore ist das per SW-decoding bemerkenswerterweise flüssig abspielbar, allerdings immer noch mit 40% Prozessorauslastung auf den 4 SMT-kernen.

Startet man es hingegen mit
mpv --vo=vaapi --hwdec=auto
spielt derselbige den File mit 8% durchschnittlicher Prozessorauslastung butterweich. Allgemein hinterlässt die Intel HD4000 unter Linux einen äußerst soliden Eindruck.


Auch ein tolles Testfile von amvnews.ru

 

[Zehkul]

Das mag natürlich sein, hast du evtl. eine url, wenn möglich eher eine kürzere Sequenz?

http://s7.directupload.net/file/d/3461/qxvffcwg_gif.htm

Ein Beispiel von vielen. Das ist NouCome (Folge 3, 9:45 … aber da gibt es jede Folge mehrfach Stellen, die schwache Rechner lahmlegen), zu finden natürlich auf Nyaa.

Alles, was in dem Gif Englisch ist, sind „Untertitel“. Dass das Rendern auch noch single threaded ist, hilft nicht unbedingt.

Ebenfalls sehr aufwändig (und definitiv hübsch gemacht): Symphogear von Commie. Der Vergleich ohne und mit Untertitel:
http://s1.directupload.net/file/d/3461/nt42vrig_gif.htm
http://s1.directupload.net/file/d/3461/dn62cxif_gif.htm

Bei solchen Untertiteln hat das nichts mit Mesa und VDPAU zu tun, das ist für jeden Untertitelrenderer ein ziemlicher Aufwand, ist ja nicht ins Video eingebrannt, sondern wird alles in Echtzeit berechnet.

Da irrst du dich.

Nein, eigentlich nicht. Mir ist aber gerade aufgefallen, dass das in noch gar keinem Release drin ist, auch dem neuen 0.24 nicht, nur Git Master. Ups.
Und ich meinte auch nicht, dass Vaapi nicht viel bringt, sondern dass die Kombination Vaapi + Opengl wohl nicht die beste ist.

Der OpenGL + Hardwaredecoding Kram ist nun sogar wieder thematisch relevant hier, das funktioniert mit vdpau im Mesa 10.0 Release oder eben nicht, keine Lust, da nachzugraben, ich werde es sehen. (In Git geht es auf alle Fälle)

 

[Zehkul]

Der OpenGL + Hardwaredecoding Kram ist nun sogar wieder thematisch relevant hier, das funktioniert mit vdpau im Mesa 10.0 Release oder eben nicht, keine Lust, da nachzugraben, ich werde es sehen.

Und es funktioniert! 1% CPU Auslastung mit OpenGL Videoausgabe über Vdpau.

Natural Selection 2 will aber immer noch nicht, meh.
Error: OpenGL version 3.1 is required
Error: Couldn't initialize the render device.

Pfff nutzt nicht Opengl Core, also wirklich. Na dann mal auf die NS2 Devs warten …