Follow up of https://bugs.freedesktop.org/show_bug.cgi?id=71448 Here is a video which hangs 100% of the times: https://mega.co.nz/#!eQhSjJQR!EEe8-taN5IspIu-RW0WQzmvKzc5fkCn282kS5ugZ_as Play with mplayer2 -vo vdpau, -vc ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau, PlanetEarthBirds.mkv
Video works perfectly on my 7870. Are you sure that's not an unrelated bug? Please try running it without any desktop effects. Best way to narrow it down would be a pure X server without anything else started.
Created attachment 93297 [details] startx This is my pure X server so I fear it's not going to happen. Anyway I just got two more crashes with KDE (one with desktop effects ON and one with desktop effects OFF) and then it worked for a couple of times. Anyway it's way too slow (I get "Your system is too SLOW to play this!" in mplayer).
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.
UVD IRQs weren't working correctly on SI. Bug is fixed upstream by new kernel release.
Is it fixed in 3.16-rc6?
(In reply to comment #5) > Is it fixed in 3.16-rc6? That fix should be in all kernels since 3.14. It was named "drm/radeon: fix UVD IRQ support on SI".
Ah, stop my fault. That was for the other bug report. Sorry, I've just messed those two up.
ArchLinux x86-64; linux 3.16; mesa git; llvm svn; Radeon HD 7950 Is it still correct? I have: $ mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo gl BENCHMARKs: VC: 3.404s VO: 17.792s A: 0.000s Sys: 1.978s = 23.174s BENCHMARK%: VC: 14.6908% VO: 76.7753% A: 0.0000% Sys: 8.5339% = 100.0000% $ mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo xv BENCHMARKs: VC: 10.609s VO: 3.479s A: 0.000s Sys: 1.867s = 15.955s BENCHMARK%: VC: 66.4934% VO: 21.8045% A: 0.0000% Sys: 11.7021% = 100.0000% $ mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo vdpau BENCHMARKs: VC: 3.319s VO: 16.936s A: 0.000s Sys: 0.644s = 20.900s BENCHMARK%: VC: 15.8826% VO: 81.0336% A: 0.0000% Sys: 3.0837% = 100.0000% $ mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo null BENCHMARKs: VC: 11.915s VO: 0.003s A: 0.000s Sys: 0.653s = 12.571s BENCHMARK%: VC: 94.7809% VO: 0.0228% A: 0.0000% Sys: 5.1963% = 100.0000% $ mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo vdpau -vc ffh264vdpau BENCHMARKs: VC: 7.402s VO: 13.679s A: 0.000s Sys: 0.692s = 21.773s BENCHMARK%: VC: 33.9957% VO: 62.8252% A: 0.0000% Sys: 3.1791% = 100.0000%
mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo gl BENCHMARKs: VC: 0.827s VO: 22.917s A: 0.000s Sys: 0.494s = 24.238s BENCHMARK%: VC: 3.4108% VO: 94.5502% A: 0.0000% Sys: 2.0390% = 100.0000% $ mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo xv BENCHMARKs: VC: 3.292s VO: 2.707s A: 0.000s Sys: 0.667s = 6.666s BENCHMARK%: VC: 49.3886% VO: 40.6098% A: 0.0000% Sys: 10.0016% = 100.0000% mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo vdpau BENCHMARKs: VC: 0.752s VO: 22.925s A: 0.000s Sys: 0.482s = 24.158s BENCHMARK%: VC: 3.1113% VO: 94.8942% A: 0.0000% Sys: 1.9945% = 100.0000% mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo null BENCHMARKs: VC: 4.836s VO: 0.004s A: 0.000s Sys: 0.391s = 5.231s BENCHMARK%: VC: 92.4320% VO: 0.0849% A: 0.0000% Sys: 7.4831% = 100.0000% mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo vdpau -vc ffh264vdpau BENCHMARKs: VC: 1.624s VO: 22.466s A: 0.000s Sys: 0.501s = 24.590s BENCHMARK%: VC: 6.6026% VO: 91.3590% A: 0.0000% Sys: 2.0384% = 100.0000%
That looks normal, I have that sample and it's 1444 frames / 60Hz = 24 seconds. You can't really turn off vsync for vdpau and mplayer doesn't do gl interop. Cpu times can mislead if cpufreq on_demand is in use as you don't know what freq the cores are in. UVD/powerplay is tuned for playback (at least on recent GPUs) if using with eg. ffmpeg you can get more perf by forcing GPU clocks to high.
Yeah, agree. The number look perfectly fine. Additional to that please don't reopen a three year old bug for this.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.