Bug 67530

Summary: VDPAU state tracker reports wrong codec level
Product: DRI Reporter: Richard Van Den Boom <rvdb>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: medium    
Version: XOrg git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
use more common defaults for the level
none
use more common defaults for the level (all cards) none

Description Richard Van Den Boom 2013-07-30 10:37:27 UTC
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.
Comment 1 Christian König 2013-07-30 11:35:58 UTC
Indeed, so far we have hardcoded the level in vlVdpDecoderQueryCapabilities.

Should be updated to correctly return the supported codec level.
Comment 2 Richard Van Den Boom 2013-07-30 11:57:45 UTC
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?
Comment 3 Christian König 2013-07-30 12:29:13 UTC
(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...
Comment 4 gurketsky 2013-08-06 21:19:36 UTC
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.
Comment 5 Christian König 2013-08-07 10:49:04 UTC
(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.
Comment 6 gurketsky 2013-08-13 16:21:14 UTC
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.
Comment 7 Christian König 2013-08-13 16:31:25 UTC
(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.
Comment 8 Christian König 2013-08-14 11:36:01 UTC
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.