Yes, but this is a separate issue I think. We fail safely, and it
doesn't matter for the common path when only PutBits is used.
That said it shouldn't be too hard to convert between YV12 and NV12 or
YUYV and UYVY. The chroma type is fixed for a given VdpVideoSurface so
it doesn't make sense to request a 4:2:2 format for a 4:2:0 surface or
vice versa.
Sounds like a plan to me.
Rico Schüller is already working on implementing conversions and from
his mail this morning it sounds like he has YUYV<->UYVY already working.
So don't worry to much about that we are going to fix that sooner or
later anyway.
Christian.
Am 07.10.2013 11:37, schrieb Grigori Goronzy:
On 07.10.2013 11:25, Christian König wrote:
Am 01.10.2013 21:12, schrieb Ilia Mirkin:
On Tue, Oct 1, 2013 at 3:06 PM, Grigori Goronzy <g...@chown.ath.cx>
wrote:
UVD can only support NV12 in the case of hardware decoding, but we
can still use all other formats for software decoding. Use the UNKNOWN
entrypoint to signal that we're not interesting in hardware decoding.
FYI, in nouveau, we use profile == UNKNOWN to determine this.
Which is probably the better way of doing this.
Yup, I'll change this.
Apart from that you also need to fix the case where the application
wants to read the surface in a different format than the decoder decoded
it, e.g. format conversion while reading ti.
Yes, but this is a separate issue I think. We fail safely, and it
doesn't matter for the common path when only PutBits is used.
That said it shouldn't be too hard to convert between YV12 and NV12 or
YUYV and UYVY. The chroma type is fixed for a given VdpVideoSurface so
it doesn't make sense to request a 4:2:2 format for a 4:2:0 surface or
vice versa.
Best regards
Grigori
Christian.
---
src/gallium/drivers/radeon/radeon_uvd.c | 7 +++++--
src/gallium/state_trackers/vdpau/query.c | 4 ++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 382b410..161dee8 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -1154,6 +1154,9 @@ boolean ruvd_is_format_supported(struct
pipe_screen *screen,
enum pipe_video_profile profile,
enum pipe_video_entrypoint
entrypoint)
{
- /* we can only handle this one anyway */
- return format == PIPE_FORMAT_NV12;
+ /* we can only handle this one with UVD */
+ if (entrypoint != PIPE_VIDEO_ENTRYPOINT_UNKNOWN)
+ return format == PIPE_FORMAT_NV12;
+
+ return vl_video_buffer_is_format_supported(screen, format,
profile, entrypoint);
}
diff --git a/src/gallium/state_trackers/vdpau/query.c
b/src/gallium/state_trackers/vdpau/query.c
index 1d35252..e7486b3 100644
--- a/src/gallium/state_trackers/vdpau/query.c
+++ b/src/gallium/state_trackers/vdpau/query.c
@@ -147,7 +147,7 @@
vlVdpVideoSurfaceQueryGetPutBitsYCbCrCapabilities(VdpDevice device,
VdpChromaTyp
pscreen,
FormatYCBCRToPipe(bits_ycbcr_format),
PIPE_VIDEO_PROFILE_UNKNOWN,
- PIPE_VIDEO_ENTRYPOINT_BITSTREAM
+ PIPE_VIDEO_ENTRYPOINT_UNKNOWN
);
pipe_mutex_unlock(dev->mutex);
@@ -398,7 +398,7 @@
vlVdpOutputSurfaceQueryPutBitsYCbCrCapabilities(VdpDevice device,
VdpRGBAFormat
(
pscreen, ycbcr_format,
PIPE_VIDEO_PROFILE_UNKNOWN,
- PIPE_VIDEO_ENTRYPOINT_BITSTREAM
+ PIPE_VIDEO_ENTRYPOINT_UNKNOWN
);
pipe_mutex_unlock(dev->mutex);
--
1.8.1.2
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
