On 08/23/2017 02:10 PM, Christian König wrote:
Am 23.08.2017 um 19:21 schrieb Leo Liu:
Since encoder only support de-interlaced buffers.
Signed-off-by: Leo Liu <leo....@amd.com>
---
src/gallium/state_trackers/va/picture.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/va/picture.c
b/src/gallium/state_trackers/va/picture.c
index b2be7af8c4..ea86ce1b3b 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -625,7 +625,8 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID
context_id)
PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
PIPE_VIDEO_CAP_SUPPORTS_INTERLACED);
- if (surf->buffer->interlaced != interlaced) {
+ if (context->decoder->entrypoint != PIPE_VIDEO_ENTRYPOINT_ENCODE &&
+ surf->buffer->interlaced != interlaced) {
I think it would be better to just use context->decoder->entrypoint in
the call above.
That should return false for interlaced when there is some encoding
going on.
Yeah. That should work too. v2 will address that, but the approach just
to fix the regression.
Look at the encode interlaced handling, it's a bit messy. since in order
to make Encode work on VAAPI, we have to use env
"VAAPI_DISABLE_INTERLACE=true" to allocate the deinterlaced buffer in
the beginning.
The problem is when buffer re-allocate to de-interlaced, the content of
YUV is there already, so the simply reallocation will lose the first few
frames.
Since I have done the similar thing on OMX to copy back YUV from
interlaced buffer to deinterlaced, I may try to do that on VAAPI to
remove env "VAAPI_DISABLE_INTERLACE"
Regards,
Leo
Regards,
Christian.
surf->templat.interlaced = screen->get_video_param(screen,
context->decoder->profile,
PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
PIPE_VIDEO_CAP_PREFERS_INTERLACED);
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
