The VDPAU collects from VDPAU drivers a certain amount of capabilities that are supposed to allow user space program to check if the decoder is able to decode a particular stream or not. These parameters can be checked by the vdpauinfo tool and the begining of the output on Nvidia hardware looks like this : ****************** display: (null) screen: 0 API version: 0 Information string: Unknown Video surface: name width height types ------------------------------------------- 420 4096 4096 NV12 YV12 422 4096 4096 UYVY YUYV Decoder capabilities: name level ref width height ------------------------------------ MPEG1 0 2 4096 4096 MPEG2_SIMPLE 3 2 4096 4096 MPEG2_MAIN 3 2 4096 4096 H264_MAIN 41 4 4096 4096 H264_HIGH 41 4 4096 4096 ******************* Right now, the output on a Zacate / Brazos E450 system looks like this : ******************* bash-4.2$ vdpauinfo display: :0 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 Video surface: name width height types ------------------------------------------- 420 16384 16384 NV12 422 16384 16384 NV12 444 16384 16384 NV12 Decoder capabilities: name level macbs width height ------------------------------------------- MPEG1 16 9216 2048 1152 MPEG2_SIMPLE 16 9216 2048 1152 MPEG2_MAIN 16 9216 2048 1152 H264_BASELINE 16 9216 2048 1152 H264_MAIN 16 9216 2048 1152 H264_HIGH 16 9216 2048 1152 VC1_SIMPLE 16 9216 2048 1152 VC1_MAIN 16 9216 2048 1152 VC1_ADVANCED 16 9216 2048 1152 MPEG4_PART2_SP 16 9216 2048 1152 MPEG4_PART2_ASP 16 9216 2048 1152 ********************* Whatever the codec, the supported level is shown to be 16 (a non-existing level for h264 at least) and the macbs (the number of macroblocks) is always the same. This confuses players like VLC which adress libvdpau directly and get this answer (16) for the supported h264 level. Players like mplayer, which do not check this, play the video using UVD without problem. So there is just an issue with the way VDPAU reports UVD capabilities : it seems to just provide some kind of default.
Indeed, so far we have hardcoded the level in vlVdpDecoderQueryCapabilities. Should be updated to correctly return the supported codec level.
Good to know! I'll stop bothering the world and his dog about that, then. :-) Is this also normal that the decoder only report NV12 and no YV12, UYVY or YUYV? Is it some hardware limitation?
(In reply to comment #2) > Good to know! I'll stop bothering the world and his dog about that, then. :-) > Is this also normal that the decoder only report NV12 and no YV12, UYVY or > YUYV? Is it some hardware limitation? Yes that's a hardware limitation, UVD can only decode to an NV12 destination. Well actually we somewhat abused the query interface here, cause VDPAU asks the driver what image formats are supported in up/downloads and not as decoding target. Should probably fix that at some point as well. On the other hand that should be really easy to do, so if anybody volunteers...
Created attachment 83741 [details] [review] use more common defaults for the level This patch adds more common defaults as level. Imho they are likely not correct for all the hardware.
(In reply to comment #4) > Created attachment 83741 [details] [review] [review] > use more common defaults for the level > > This patch adds more common defaults as level. Imho they are likely not > correct for all the hardware. Not bad for a first try, but I have some minor comments: > return true; > case PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE: > return true; >+ case PIPE_VIDEO_CAP_MAX_LEVEL: >+ switch (profile) { >+ case PIPE_VIDEO_PROFILE_MPEG1: The new code has a different indention, the radeon code uses tabs instead of spaces, please fix. Additional to that you need to fix all drivers to handle the new CAP, just "grep -R PIPE_VIDEO_CAP_SUPPORTED src/gallium/drivers" to find all those places. With that fixed please send the patch to the mesa maillinglist for review.
Created attachment 84021 [details] [review] use more common defaults for the level (all cards) I fixed the white spaces and added all drivers. The problem I see is, the default values may be not correct. This also holds true for the nouveau driver. We may need some vdpauinfo from the binary driver to fix that. If that's not much of a problem, I'll submit this patch.
(In reply to comment #6) > Created attachment 84021 [details] [review] [review] > use more common defaults for the level (all cards) > > I fixed the white spaces and added all drivers. The problem I see is, the > default values may be not correct. This also holds true for the nouveau > driver. We may need some vdpauinfo from the binary driver to fix that. If > that's not much of a problem, I'll submit this patch. Looks pretty good. Those values are definitely more reasonable than the hardcoded "16", so it is an improvements even when they might not be 100% correctly. Please submit to the maillinglist and CC me.
Just commited the fix to master, please retest and close if solved.
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.