Playing h264 MKV PAL files with VDPAU on AMD UVD causes stalls
I have a system with an AMD Brazos processor that recently got support for the on-chip UVD decoding device with Linux. It is supposed to be accessed using VDPAU and has a Gallium state tracker for that. I try to play on this computer MKV files created from DVD RIPs (legals, I own the DVDs) that I store on a file server accessed through NFS by all our computers in our house. But quite regularly, I get "picture is too late to be displayed" messages on the console during the play until at some point, a "ES_OUT_SET_(GROUP_)PCR is called too late" occurs and the movie stalls for several second until it continues a bit later. It's worth noticing :
- The MKV can be played with issues on the same computer with Mplayer using VDPAU
- The same file on the same computer could be played without issue by VLC without VDPAU (I guess it's using XVideo in that case).
- The same file on another computer that doesn't have UVD hardware decoding abilities works without any error or even "picture too late" message.
Activity
Although not a problem as such, this is clearly a VDPAU driver bug:
[0x7f08a000da98] vdpau_chroma filter error: video color space matrix failure: An invalid pointer was provided. Typically, this means that a NULL pointer was provided for an 'output' parameter.And this is also a VDPAU driver bug and probably the real problem:
[0x7f08a0001248] vdpau_display vout display debug: surface status: 2It makes no sense for the surface to have status 2 here.
added Status::not VLC label
Well, I have the surface status message on the system with no hardware decoding stuff, so I don't think it's related to the hardware driver, maybe to VDPAU 0.7 lib, though I had the same message with 0.6. As for the first message, I'll report it. I guess the UVD hardware decoder just doesn't support chroma filtering but it should be better handled.
Still, Mplayer does manage to play the file without stalls on the exact same system using the hardware decoding chip. So I'm willing to agree that it is a hardware driver issue but I think it should be a bit more investigated from your side first since the above argument do not explain why Mplayer works and not VLC.
-
Replying to [comment:2 rvdboom]:
Well, I have the surface status message on the system with no hardware decoding stuff, so I don't think it's related to the hardware driver, maybe to VDPAU 0.7 lib, though I had the same message with 0.6.
The VDPAU library is just a glorified dlopen() wrapper. It cannot cause this. This is a bug in the Gallium Radeon driver.
As for the first message, I'll report it. I guess the UVD hardware decoder just doesn't support chroma filtering but it should be better handled.
AFAIK, it is not an optional feature.
Still, Mplayer does manage to play the file without stalls on the exact same system using the hardware decoding chip.
That's a lame argument. My NVIDIA card manages to play the file without stalls with VLC.
So I'm willing to agree that it is a hardware driver issue but I think it should be a bit more investigated from your side first since the above argument do not explain why Mplayer works and not VLC.
I cannot investigate it since I do not have adequate hardware. Even if I did, I wouldn't spend hours to trace an issue with a driver that is anyway known to be buggy.
Replying to [comment:3 courmisch]:
The VDPAU library is just a glorified dlopen() wrapper. It cannot cause this. This is a bug in the Gallium Radeon driver. A bug that also occurs here on another system with no hardware and thus no use of any Gallium Radeon driver. I'm talking about the "surface status 2" message you consider to be the hint for a hardware error.
AFAIK, it is not an optional feature. OK.
That's a lame argument. My NVIDIA card manages to play the file without stalls with VLC. ?? That's your argument? On the same system, playing the same file using the same hardware, Mplayer works fine and not VLC. And your argument is that VLC cannot be buggy because you can play with it another file on another system with different hardware? Well, no point in discussing this, I guess.
I cannot investigate it since I do not have adequate hardware. Even if I did, I wouldn't spend hours to trace an issue with a driver that is anyway known to be buggy. I understood that and I can understand your position. Let's drop it.
-
Replying to [comment:4 rvdboom]:
Replying to [comment:3 courmisch]:
The VDPAU library is just a glorified dlopen() wrapper. It cannot cause this. This is a bug in the Gallium Radeon driver. A bug that also occurs here on another system with no hardware and thus no use of any Gallium Radeon driver. I'm talking about the "surface status 2" message you consider to be the hint for a hardware error.
I never said it was a hardware error. It could be a VLC bug, a Gallium VDPAU driver bug, a Gallium VDPAU state tracker bug, a device driver bug or a hardware bug, and the later does not look the most likely to me. But it makes no sense to have status 2 where the message comes (hence the debug message...). This is a strong hint that something is horribly wrong within the VDPAU driver or state tracker.
That's a lame argument. My NVIDIA card manages to play the file without stalls with VLC. ?? That's your argument?
It's just the same as the argument you made. It is a logical fallacy. Only the combination of VLC and Gallium fails, and that proves nothing about whether it is a VLC, a Gallium 3D or a Radeon driver bug.
On the same system, playing the same file using the same hardware, Mplayer works fine and not VLC. And your argument is that VLC cannot be buggy because you can play with it another file on another system with different hardware?
That only proves that Mplayer uses VDPAU different than VLC does. And that is no news. Differently does not mean wrongly. From the broken CSC matrix generation, the suspicious surface status, and the recently fixed invalid decoder capabilities, it is however clear that the Gallium 3D / Radeon driver for VDPAU is buggy. In fact, I guess it was designed to match Mplayer usage, rather than to match the VDPAU specification. Indeed Mplayer does not even use the decoder capabilities and the CSC matrix generation, so those bugs are invisible in Mplayer.
Well, no point in discussing this, I guess.
At least, there is nothing I can do about this bug at things stand. Someone with adequate hardware should debug it, but even then, I'd advise debugging the Gallium driver first.
I cannot investigate it since I do not have adequate hardware. Even if I did, I wouldn't spend hours to trace an issue with a driver that is anyway known to be buggy. I understood that and I can understand your position. Let's drop it.
In my opinion, it should be reported to Mesa rather than dropped.
Replying to [ticket:9281 rvdboom]:
I have a system with an AMD Brazos processor that recently got support for the on-chip UVD decoding device with Linux. It is supposed to be accessed using VDPAU and has a Gallium state tracker for that. I try to play on this computer MKV files created from DVD RIPs (legals, I own the DVDs) that I store on a file server accessed through NFS by all our computers in our house. But quite regularly, I get "picture is too late to be displayed" messages on the console during the play until at some point, a "ES_OUT_SET_(GROUP_)PCR is called too late" occurs and the movie stalls for several second until it continues a bit later. It's worth noticing :
- The MKV can be played with issues on the same computer with Mplayer using VDPAU
- The same file on the same computer could be played without issue by VLC without VDPAU (I guess it's using XVideo in that case).
- The same file on another computer that doesn't have UVD hardware decoding abilities works without any error or even "picture too late" message.
