Comment # 3
on bug 74335
from darkbasic
I switched from libav/mplayer2 to ffmpeg/mplayer git and the crash seems gone. Bye bye libav. Being stable I did some more tests and unfortunately performance sucks so I renamed the bug report. Benchmarking the video output: ffh264 software decoder + gl/xv/vdpau ~ $ mplayer -benchmark -nosound -lavdopts threads=16 PlanetEarthBirds.mkv -vo gl BENCHMARKs: VC: 3.403s VO: 7.530s A: 0.000s Sys: 0.672s = 11.605s BENCHMARK%: VC: 29.3238% VO: 64.8892% A: 0.0000% Sys: 5.7870% = 100.0000% ~ $ mplayer -benchmark -nosound -lavdopts threads=16 PlanetEarthBirds.mkv -vo xv BENCHMARKs: VC: 7.878s VO: 2.162s A: 0.000s Sys: 1.040s = 11.080s BENCHMARK%: VC: 71.0951% VO: 19.5154% A: 0.0000% Sys: 9.3896% = 100.0000% ~ $ mplayer -benchmark -nosound -lavdopts threads=16 PlanetEarthBirds.mkv -vo vdpau BENCHMARKs: VC: 0.863s VO: 43.888s A: 0.000s Sys: 0.550s = 45.300s BENCHMARK%: VC: 1.9042% VO: 96.8823% A: 0.0000% Sys: 1.2135% = 100.0000% With both -vo gl and -vo xv it took ~11.080s while with -vo vdpau it took 45.300s. -vo vdpau is *4x* slower. Benchmarking the video decoder: ffh264/ffh264vdpau + vo null ~ $ mplayer -benchmark -nosound -lavdopts threads=16 PlanetEarthBirds.mkv -vo null BENCHMARKs: VC: 8.855s VO: 0.002s A: 0.000s Sys: 0.493s = 9.350s BENCHMARK%: VC: 94.7024% VO: 0.0262% A: 0.0000% Sys: 5.2714% = 100.0000% ~ $ mplayer -benchmark -nosound PlanetEarthBirds.mkv -vo null -vc ffh264vdpau It seems I can't use the null video output with the hardware decoder ffh264vdpau: I get tons of "Too many buffered pts". It does support only -vo vdpau, not even xv or gl. Such a pity. (is it a known limitation/bug?) Let's do a more complete benchmark: ffh264+xv vs ffh264vdpau+vdpau We already saw ffh264+xv took 11.080s, let's see how ffh264vdpau+vdpau performs. ~ $ mplayer -benchmark -nosound PlanetEarthBirds.mkv -vo vdpau -vc ffh264vdpau BENCHMARKs: VC: 0.869s VO: 44.581s A: 0.000s Sys: 0.374s = 45.824s BENCHMARK%: VC: 1.8955% VO: 97.2876% A: 0.0000% Sys: 0.8169% = 100.0000% As expected it's still 4 times slower because the bottleneck is obviously the vdpau video output and not the ffh264vdpau decoder. Being 4x slower vdpau is completely useless right now :( Please note that I disabled desktop compositing before doing the tests.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel