[FFmpeg-devel,1/2] avcodec/vaapi: slice_vertical_position starts from zero for the second field

Submitted by Jerome Borsboom on May 9, 2018, 5:50 a.m.

Details

Message ID dd48f849-d8b8-2040-6de2-7ebe9a2995ac@carpalis.nl
State New
Headers show

Commit Message

Jerome Borsboom May 9, 2018, 5:50 a.m.
Contrary to VC-1 spec, VAAPI expects the row address of the first
macroblock row in the first slice to start from zero for the second
field in a field interlaced picture.

Signed-off-by: Jerome Borsboom <jerome.borsboom@carpalis.nl>
---
This patch set adds support for hardware decoding multi-slice field interlaced
pictures. With this patch set, the SA10180 test file decodes correctly with
VAAPI hardware acceleration. This was succesfully tested on Intel Haswell platform.

 libavcodec/vaapi_vc1.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Comments

Haihao Xiang May 9, 2018, 8:54 a.m.
On Wed, 2018-05-09 at 07:50 +0200, Jerome Borsboom wrote:
> Contrary to VC-1 spec, VAAPI expects the row address of the first

> macroblock row in the first slice to start from zero for the second

> field in a field interlaced picture.

> 

> Signed-off-by: Jerome Borsboom <jerome.borsboom@carpalis.nl>

> ---

> This patch set adds support for hardware decoding multi-slice field interlaced

> pictures. With this patch set, the SA10180 test file decodes correctly with

> VAAPI hardware acceleration. This was succesfully tested on Intel Haswell

> platform.

> 


I still see lots of artifacts for a multi-slice field interfaced VC-1 video on
Coffee Lake, maybe we should fix it in the driver 

Thanks
Haihao


>  libavcodec/vaapi_vc1.c | 8 +++++++-

>  1 file changed, 7 insertions(+), 1 deletion(-)

> 

> diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c

> index bdb5e24cc5..921ca6391b 100644

> --- a/libavcodec/vaapi_vc1.c

> +++ b/libavcodec/vaapi_vc1.c

> @@ -467,6 +467,7 @@ static int vaapi_vc1_decode_slice(AVCodecContext *avctx,

> const uint8_t *buffer,

>      const MpegEncContext *s = &v->s;

>      VAAPIDecodePicture *pic = s->current_picture_ptr-

> >hwaccel_picture_private;

>      VASliceParameterBufferVC1 slice_param;

> +    int mb_height;

>      int err;

>  

>      /* Current bit buffer is beyond any marker for VC-1, so skip it */

> @@ -475,12 +476,17 @@ static int vaapi_vc1_decode_slice(AVCodecContext *avctx,

> const uint8_t *buffer,

>          size -= 4;

>      }

>  

> +    if (v->fcm == ILACE_FIELD)

> +        mb_height = avctx->coded_height + 31 >> 5;

> +    else

> +        mb_height = avctx->coded_height + 15 >> 4;

> +

>      slice_param = (VASliceParameterBufferVC1) {

>          .slice_data_size         = size,

>          .slice_data_offset       = 0,

>          .slice_data_flag         = VA_SLICE_DATA_FLAG_ALL,

>          .macroblock_offset       = get_bits_count(&s->gb),

> -        .slice_vertical_position = s->mb_y,

> +        .slice_vertical_position = s->mb_y % mb_height,

>      };

>  

>      err = ff_vaapi_decode_make_slice_buffer(avctx, pic,
Jerome Borsboom May 9, 2018, noon
>> Contrary to VC-1 spec, VAAPI expects the row address of the first
>> macroblock row in the first slice to start from zero for the second
>> field in a field interlaced picture.
>> 
>> Signed-off-by: Jerome Borsboom <jerome.borsboom at carpalis.nl>
>> ---
>> This patch set adds support for hardware decoding multi-slice field interlaced
>> pictures. With this patch set, the SA10180 test file decodes correctly with
>> VAAPI hardware acceleration. This was succesfully tested on Intel Haswell
>> platform.
>> 
> 
> I still see lots of artifacts for a multi-slice field interfaced VC-1 video on
> Coffee Lake, maybe we should fix it in the driver 
> 
> Thanks
> Haihao

I suppose you also applied the second part of this patch and still see
artifacts. I cannot check for Coffee Lake, but there may be issues with
the VAAPI driver for CL platform. The patches are just a copy of the
multi-slice support for frame interlaced images, so nothing special there.

Could you share (part of) the video you used to check on Coffee Lake so
that I can see how Haswell performs?


Regards,
Jerome
Haihao Xiang May 10, 2018, 7:03 a.m.
On Wed, 2018-05-09 at 14:00 +0200, Jerome Borsboom wrote:
> > > Contrary to VC-1 spec, VAAPI expects the row address of the first

> > > macroblock row in the first slice to start from zero for the second

> > > field in a field interlaced picture.

> > > 

> > > Signed-off-by: Jerome Borsboom <jerome.borsboom at carpalis.nl>

> > > ---

> > > This patch set adds support for hardware decoding multi-slice field

> > > interlaced

> > > pictures. With this patch set, the SA10180 test file decodes correctly

> > > with

> > > VAAPI hardware acceleration. This was succesfully tested on Intel Haswell

> > > platform.

> > > 

> > 

> > I still see lots of artifacts for a multi-slice field interfaced VC-1 video

> > on

> > Coffee Lake, maybe we should fix it in the driver 

> > 

> > Thanks

> > Haihao

> 

> I suppose you also applied the second part of this patch and still see

> artifacts. I cannot check for Coffee Lake, but there may be issues with

> the VAAPI driver for CL platform. The patches are just a copy of the

> multi-slice support for frame interlaced images, so nothing special there.

> 

> Could you share (part of) the video you used to check on Coffee Lake so

> that I can see how Haswell performs?

> 


I apologize that I used a video with Luma/Chroma scaling set which is not
supported by the driver. I confirmed your patchset works for me with other
multi-slice field interfaced VC-1 video.

Thanks
Haihao


> 

> Regards,

> Jerome

> _______________________________________________

> ffmpeg-devel mailing list

> ffmpeg-devel@ffmpeg.org

> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Patch hide | download patch | download mbox

diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
index bdb5e24cc5..921ca6391b 100644
--- a/libavcodec/vaapi_vc1.c
+++ b/libavcodec/vaapi_vc1.c
@@ -467,6 +467,7 @@  static int vaapi_vc1_decode_slice(AVCodecContext *avctx, const uint8_t *buffer,
     const MpegEncContext *s = &v->s;
     VAAPIDecodePicture *pic = s->current_picture_ptr->hwaccel_picture_private;
     VASliceParameterBufferVC1 slice_param;
+    int mb_height;
     int err;
 
     /* Current bit buffer is beyond any marker for VC-1, so skip it */
@@ -475,12 +476,17 @@  static int vaapi_vc1_decode_slice(AVCodecContext *avctx, const uint8_t *buffer,
         size -= 4;
     }
 
+    if (v->fcm == ILACE_FIELD)
+        mb_height = avctx->coded_height + 31 >> 5;
+    else
+        mb_height = avctx->coded_height + 15 >> 4;
+
     slice_param = (VASliceParameterBufferVC1) {
         .slice_data_size         = size,
         .slice_data_offset       = 0,
         .slice_data_flag         = VA_SLICE_DATA_FLAG_ALL,
         .macroblock_offset       = get_bits_count(&s->gb),
-        .slice_vertical_position = s->mb_y,
+        .slice_vertical_position = s->mb_y % mb_height,
     };
 
     err = ff_vaapi_decode_make_slice_buffer(avctx, pic,