Am 25.08.2017 um 17:15 schrieb Leo Liu:


On 08/25/2017 10:53 AM, Leo Liu wrote:


On 08/25/2017 02:57 AM, Christian König wrote:
Am 24.08.2017 um 20:49 schrieb Leo Liu:
v2: use deinterlace common function
v3: make sure deinterlace only

Signed-off-by: Leo Liu <leo....@amd.com>
---
  src/gallium/state_trackers/va/picture.c | 22 ++++++++++++++++------
  1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture.c b/src/gallium/state_trackers/va/picture.c
index 6c3c4fe..aa4062d 100644
--- a/src/gallium/state_trackers/va/picture.c
+++ b/src/gallium/state_trackers/va/picture.c
@@ -613,17 +613,22 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
     mtx_lock(&drv->mutex);
     surf = handle_table_get(drv->htab, context->target_id);
     context->mpeg4.frame_num++;
-
     screen = context->decoder->context->screen;
interlaced = screen->get_video_param(screen, context->decoder->profile,
context->decoder->entrypoint,
PIPE_VIDEO_CAP_SUPPORTS_INTERLACED);
       if (surf->buffer->interlaced != interlaced) {
- surf->templat.interlaced = screen->get_video_param(screen, context->decoder->profile,
- PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
- PIPE_VIDEO_CAP_PREFERS_INTERLACED);
-      realloc = true;
+ interlaced = screen->get_video_param(screen, context->decoder->profile,
+ context->decoder->entrypoint,
+ PIPE_VIDEO_CAP_PREFERS_INTERLACED);
+      if (!interlaced) {
+         /* The current cases for buffer reallocation are
+            all from the interlaced to the deinterlaced,
+            and there is no case for the other way around */
+         surf->templat.interlaced = false;
+         realloc = true;
+      }

Should we bail out with an error here when it's the other way around?
Although I cannot think of any of case that to get buffer Interlaced now, It's still a good idea to bail out here when it happnens
Will add it in v4.

It's not a error when case like buffer is deinterlaced, and interlaced result from query. What we need to do is to do nothing, just ignores.
I have sent out v4, please ignore it, it won't work.

Well that's not correct either.

When the buffer is allocated as progressive and the codec doesn't supports that we should certainly do something.

Either bail out as an error when we encode because we can't convert progressive->interlaced (just the other way around) and/or reallocate for decoding.

Christian.


Leo





Thanks,
Leo




Would be nice if we could at least sanely handle that case.

Apart from that it looks good to me,
Christian.

     }
if (u_reduce_video_profile(context->templat.profile) == PIPE_VIDEO_FORMAT_JPEG && @@ -640,13 +645,18 @@ vlVaEndPicture(VADriverContextP ctx, VAContextID context_id)
     }
       if (realloc) {
-      surf->buffer->destroy(surf->buffer);
+      struct pipe_video_buffer *old_buf = surf->buffer;
if (vlVaHandleSurfaceAllocate(ctx, surf, &surf->templat) != VA_STATUS_SUCCESS) {
+         old_buf->destroy(old_buf);
           mtx_unlock(&drv->mutex);
           return VA_STATUS_ERROR_ALLOCATION_FAILED;
        }
+ if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) + vl_compositor_yuv_deint(&drv->cstate, &drv->compositor, old_buf, surf->buffer);
+
+      old_buf->destroy(old_buf);
        context->target = surf->buffer;
     }





_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to