| Summary: | VDPAU state tracker reports wrong codec level | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Richard Van Den Boom <rvdb> | ||||||
| Component: | DRM/Radeon | Assignee: | 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
Richard Van Den Boom
2013-07-30 10:37:27 UTC
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.