| Priority | medium |
|---|---|
| Bug ID | 81579 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | VDPAU: videos slow to a crawl when more than 1 video is playing |
| Severity | normal |
| Classification | Unclassified |
| OS | Linux (All) |
| Reporter | joaoboia@outlook.com |
| Hardware | x86-64 (AMD64) |
| Status | NEW |
| Version | 10.2 |
| Component | Drivers/Gallium/r600 |
| Product | Mesa |
If you try to view more than one video using hardware decoding videos will slow down and become unwatchable. For example when try use two VLC instances playing different videos or one video on VLC and one on XBMC or one video on XBMC and another on Firefox. Not sure if there's an actual hardware limitation on this or not. If it is a limitation of the hardware, it should deny access to the application so it can revert to software decoding.
There is no particular hardware limitation - multiple concurrent UVD contexts are supported. This worked for me not long ago. Unless you try to play multiple 1080p60 videos at the same time or something like that, performance should be adequate. I'm not really sure if it is reasonably possible to catch these cases. Do you have trouble with concurrent UVD usage regardless of video codec and profile? E.g. does it also happen if you try to play two rather low-res, low-fps videos at the same time?
It's mainly if you have two 1080p videos at 30FPS, with one at 1080p and one at 720p video it plays fine with no slowdowns.
That just sounds like your hardware is to slow to handle two 1= 080p videos. What hardware are you using? Apart from that falling back to software decoding if the hardware decoding capacity is used up is job of the media player application. Denying decodin= g if we already have a stream playing would just result in an black screen.
(In reply to comment #3) > That just sounds like your hardware is to slow to handle two 1080p videos. > What hardware are you using? > > Apart from that falling back to software decoding if the hardware decoding > capacity is used up is job of the media player application. Denying decoding > if we already have a stream playing would just result in an black screen. It's a HD4770, it would be UVD 2.2 I think.
Please provide your full dmesg with dpm enabled, but that soun= ds like your card just doesn't have enough power for two 1080p streams.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | NOTABUG |
>[ 1.093019] =3D=3D power state 2 =
=3D=3D
>[ 1.093019] ui class: none
>[ 1.093020] internal class: uvd=20
>[ 1.093021] caps: video=20
>[ 1.093022] uvd vclk: 48000 dclk: 38000
>[ 1.093023] power level 0 sclk: 50000 mclk: 80000 vddc: 1000
>[ 1.093024] power level 1 sclk: 50000 mclk: 80000 vddc: 1000
>[ 1.093025] power level 2 sclk: 50000 mclk: 80000 vddc: 1000
The power table indeed has only a single UVD performance level and that doe=
sn't
looks like it is suitable for handling two 1080p streams at the same time.
You need at least a vclk of 533Mhz and a dclk of 400Mhz for that. You can t=
ry
to hack into the kernel and overclock the UVD block, but I don't advise to =
do
so. OEMs usually have a good reason for limiting the clocks to a lower leve=
l.
Anyway that's clearly not a driver bug, cause the kernel does what it is
supposed to do.