On Sat, Apr 2, 2016 at 5:48 PM, Mark Thompson <s...@jkqxz.net> wrote:

> Commit ca2f19b9cc37be509d85f05c8f902860475905f8 modified the meaning of
> H264SliceContext.gb: it is now initialised at the start of the NAL unit
> header, rather than at the start of the slice header.  The VAAPI slice
> decoder uses the offset after parsing to determine the offset of the
> slice data in the bitstream, so with the changed meaning we no longer
> need to add the extra byte to account for the NAL unit header because
> it is now included directly.
> ---
>  libavcodec/vaapi_h264.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
> index 431a428..2e2626e 100644
> --- a/libavcodec/vaapi_h264.c
> +++ b/libavcodec/vaapi_h264.c
> @@ -328,7 +328,7 @@ static int vaapi_h264_decode_slice(AVCodecContext
> *avctx,
>      slice_param = (VASliceParameterBufferH264
> *)ff_vaapi_alloc_slice(avctx->hwaccel_context, buffer, size);
>      if (!slice_param)
>          return -1;
> -    slice_param->slice_data_bit_offset          = get_bits_count(&sl->gb)
> + 8; /* bit buffer started beyond nal_unit_type */
> +    slice_param->slice_data_bit_offset          = get_bits_count(&sl->gb);
>      slice_param->first_mb_in_slice              = (sl->mb_y >>
> FIELD_OR_MBAFF_PICTURE(h)) * h->mb_width + sl->mb_x;
>      slice_param->slice_type                     =
> ff_h264_get_slice_type(sl);
>      slice_param->direct_spatial_mv_pred_flag    = sl->slice_type ==
> AV_PICTURE_TYPE_B ? sl->direct_spatial_mv_pred : 0;
> --
> 2.8.0.rc3


LGTM.

Tim
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to