[FFmpeg-devel] [PATCH v3 1/3] lavc/decode: Warp get_hw_config function

[FFmpeg-devel] [PATCH v3 1/3] lavc/decode: Warp get_hw_config function

[Fei Wang]

From: Linjie Fu <linjie.fu@intel.com>

Wrap the procedure of getting the hardware config from a pixel format
into a function.

Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
---
 libavcodec/decode.c | 31 +++++++++++++++++++------------
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 75373989c6..3b69426c09 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1156,6 +1156,24 @@ static void hwaccel_uninit(AVCodecContext *avctx)
     av_buffer_unref(&avctx->hw_frames_ctx);
 }
 
+static const AVCodecHWConfigInternal *get_hw_config(AVCodecContext *avctx, enum AVPixelFormat fmt)
+{
+    const AVCodecHWConfigInternal *hw_config;
+
+    if (!ffcodec(avctx->codec)->hw_configs)
+        return NULL;
+
+    for (int i = 0;; i++) {
+        hw_config = ffcodec(avctx->codec)->hw_configs[i];
+        if (!hw_config)
+            return NULL;
+        if (hw_config->public.pix_fmt == fmt)
+            return hw_config;
+    }
+
+    return NULL;
+}
+
 int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt)
 {
     const AVPixFmtDescriptor *desc;
@@ -1213,18 +1231,7 @@ int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt)
             break;
         }
 
-        if (ffcodec(avctx->codec)->hw_configs) {
-            for (i = 0;; i++) {
-                hw_config = ffcodec(avctx->codec)->hw_configs[i];
-                if (!hw_config)
-                    break;
-                if (hw_config->public.pix_fmt == user_choice)
-                    break;
-            }
-        } else {
-            hw_config = NULL;
-        }
-
+        hw_config = get_hw_config(avctx, user_choice);
         if (!hw_config) {
             // No config available, so no extra setup required.
             ret = user_choice;
-- 
2.25.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v3 2/3] lavc/decode: Add internal surface re-allocate method for hwaccel

[Fei Wang]

From: Linjie Fu <linjie.fu@intel.com>

Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able to
re-allocate surface internally through ff_decode_get_hw_frames_ctx.
So that hwaccels don't need to reinitialize all hw related configs
when decode resolution change, just need to re-allocate new surface
by using new resolution.

Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
---
 libavcodec/decode.c   | 36 ++++++++++++++++++++++++++++++++++++
 libavcodec/hwconfig.h |  1 +
 2 files changed, 37 insertions(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 3b69426c09..6a22627036 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1174,6 +1174,33 @@ static const AVCodecHWConfigInternal *get_hw_config(AVCodecContext *avctx, enum
     return NULL;
 }
 
+static int hwaccel_realloc_surface(AVCodecContext *avctx)
+{
+    const AVCodecHWConfigInternal *hw_config;
+    int ret;
+
+    if (avctx->hw_frames_ctx)
+        av_buffer_unref(&avctx->hw_frames_ctx);
+
+    hw_config = get_hw_config(avctx, avctx->pix_fmt);
+    if (!hw_config)
+        return AV_PIX_FMT_NONE;
+
+    if (avctx->hw_device_ctx &&
+        hw_config->public.methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX) {
+        const AVHWDeviceContext *device_ctx =
+                (AVHWDeviceContext*)avctx->hw_device_ctx->data;
+        ret = ff_decode_get_hw_frames_ctx(avctx, device_ctx->type);
+        if (ret < 0) {
+            av_log(avctx, AV_LOG_WARNING, "Failed to re-allocate hwaccel surface internally.\n");
+            return AV_PIX_FMT_NONE;
+        }
+    } else
+        return AV_PIX_FMT_NONE;
+
+    return hw_config->public.pix_fmt;
+}
+
 int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt)
 {
     const AVPixFmtDescriptor *desc;
@@ -1200,6 +1227,15 @@ int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt)
         return AV_PIX_FMT_NONE;
 
     for (;;) {
+        if (avctx->internal->hwaccel_priv_data &&
+            avctx->hwaccel->caps_internal & HWACCEL_CAP_INTERNAL_ALLOC) {
+            err = hwaccel_realloc_surface(avctx);
+            if (err < 0)
+                av_log(avctx, AV_LOG_WARNING, "Try to re-initialize all.\n");
+            else
+                return err;
+        }
+
         // Remove the previous hwaccel, if there was one.
         hwaccel_uninit(avctx);
 
diff --git a/libavcodec/hwconfig.h b/libavcodec/hwconfig.h
index 721424912c..7405c66c07 100644
--- a/libavcodec/hwconfig.h
+++ b/libavcodec/hwconfig.h
@@ -24,6 +24,7 @@
 
 
 #define HWACCEL_CAP_ASYNC_SAFE      (1 << 0)
+#define HWACCEL_CAP_INTERNAL_ALLOC  (1 << 1)
 
 
 typedef struct AVCodecHWConfigInternal {
-- 
2.25.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v3 3/3] lavc/vaapi_vp9: add surface internal re-allocation capability

[Fei Wang]

From: Linjie Fu <linjie.fu@intel.com>

Surfaces need to bound to a vaContext when context is created before
VAAPI 1.0.0, it need to reset context if surface change. So re-allocation
capability only available after VAAPI 1.0.0.

Detail changes in VAAPI:
https://github.com/intel/libva/commit/492b692005ccd0d8da190209d5b3ae7b7825f4b8

Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
---
update:
1. add va check version 1.0.0

 libavcodec/vaapi_vp9.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
index 776382f683..7dce0250a0 100644
--- a/libavcodec/vaapi_vp9.c
+++ b/libavcodec/vaapi_vp9.c
@@ -181,5 +181,9 @@ const AVHWAccel ff_vp9_vaapi_hwaccel = {
     .uninit               = ff_vaapi_decode_uninit,
     .frame_params         = ff_vaapi_common_frame_params,
     .priv_data_size       = sizeof(VAAPIDecodeContext),
+#if VA_CHECK_VERSION(1, 0, 0)
+    .caps_internal        = HWACCEL_CAP_ASYNC_SAFE | HWACCEL_CAP_INTERNAL_ALLOC,
+#else
     .caps_internal        = HWACCEL_CAP_ASYNC_SAFE,
+#endif
 };
-- 
2.25.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 1/3] lavc/decode: Warp get_hw_config function

[Wang, Fei W]

On Tue, 2022-08-23 at 16:19 +0800, Fei Wang wrote:
> From: Linjie Fu <linjie.fu@intel.com>
> 
> Wrap the procedure of getting the hardware config from a pixel format
> into a function.
> 
> Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> Signed-off-by: Fei Wang <fei.w.wang@intel.com>
> ---
>  libavcodec/decode.c | 31 +++++++++++++++++++------------
>  1 file changed, 19 insertions(+), 12 deletions(-)
> 
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 75373989c6..3b69426c09 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1156,6 +1156,24 @@ static void hwaccel_uninit(AVCodecContext
> *avctx)
>      av_buffer_unref(&avctx->hw_frames_ctx);
>  }
>  
> +static const AVCodecHWConfigInternal *get_hw_config(AVCodecContext
> *avctx, enum AVPixelFormat fmt)
> +{
> +    const AVCodecHWConfigInternal *hw_config;
> +
> +    if (!ffcodec(avctx->codec)->hw_configs)
> +        return NULL;
> +
> +    for (int i = 0;; i++) {
> +        hw_config = ffcodec(avctx->codec)->hw_configs[i];
> +        if (!hw_config)
> +            return NULL;
> +        if (hw_config->public.pix_fmt == fmt)
> +            return hw_config;
> +    }
> +
> +    return NULL;
> +}
> +
>  int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat
> *fmt)
>  {
>      const AVPixFmtDescriptor *desc;
> @@ -1213,18 +1231,7 @@ int ff_get_format(AVCodecContext *avctx, const
> enum AVPixelFormat *fmt)
>              break;
>          }
>  
> -        if (ffcodec(avctx->codec)->hw_configs) {
> -            for (i = 0;; i++) {
> -                hw_config = ffcodec(avctx->codec)->hw_configs[i];
> -                if (!hw_config)
> -                    break;
> -                if (hw_config->public.pix_fmt == user_choice)
> -                    break;
> -            }
> -        } else {
> -            hw_config = NULL;
> -        }
> -
> +        hw_config = get_hw_config(avctx, user_choice);
>          if (!hw_config) {
>              // No config available, so no extra setup required.
>              ret = user_choice;

Ping, any more comments on V3?

Thanks
Fei

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 1/3] lavc/decode: Warp get_hw_config function

[Xiang, Haihao]

On Wed, 2022-08-31 at 01:20 +0000, Wang, Fei W wrote:
> On Tue, 2022-08-23 at 16:19 +0800, Fei Wang wrote:
> > From: Linjie Fu <linjie.fu@intel.com>
> > 
> > Wrap the procedure of getting the hardware config from a pixel format
> > into a function.
> > 
> > Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> > Signed-off-by: Fei Wang <fei.w.wang@intel.com>
> > ---
> >  libavcodec/decode.c | 31 +++++++++++++++++++------------
> >  1 file changed, 19 insertions(+), 12 deletions(-)
> > 
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 75373989c6..3b69426c09 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1156,6 +1156,24 @@ static void hwaccel_uninit(AVCodecContext
> > *avctx)
> >      av_buffer_unref(&avctx->hw_frames_ctx);
> >  }
> >  
> > +static const AVCodecHWConfigInternal *get_hw_config(AVCodecContext
> > *avctx, enum AVPixelFormat fmt)
> > +{
> > +    const AVCodecHWConfigInternal *hw_config;
> > +
> > +    if (!ffcodec(avctx->codec)->hw_configs)
> > +        return NULL;
> > +
> > +    for (int i = 0;; i++) {
> > +        hw_config = ffcodec(avctx->codec)->hw_configs[i];
> > +        if (!hw_config)
> > +            return NULL;
> > +        if (hw_config->public.pix_fmt == fmt)
> > +            return hw_config;
> > +    }
> > +
> > +    return NULL;
> > +}
> > +
> >  int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat
> > *fmt)
> >  {
> >      const AVPixFmtDescriptor *desc;
> > @@ -1213,18 +1231,7 @@ int ff_get_format(AVCodecContext *avctx, const
> > enum AVPixelFormat *fmt)
> >              break;
> >          }
> >  
> > -        if (ffcodec(avctx->codec)->hw_configs) {
> > -            for (i = 0;; i++) {
> > -                hw_config = ffcodec(avctx->codec)->hw_configs[i];
> > -                if (!hw_config)
> > -                    break;
> > -                if (hw_config->public.pix_fmt == user_choice)
> > -                    break;
> > -            }
> > -        } else {
> > -            hw_config = NULL;
> > -        }
> > -
> > +        hw_config = get_hw_config(avctx, user_choice);
> >          if (!hw_config) {
> >              // No config available, so no extra setup required.
> >              ret = user_choice;
> 
> Ping, any more comments on V3?
> 

The patchset LGTM and works well for me, I'll apply this patchset if no more
comment.

-Haihao


_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 2/3] lavc/decode: Add internal surface re-allocate method for hwaccel

[Mark Thompson]

On 23/08/2022 09:19, Fei Wang wrote:
> From: Linjie Fu <linjie.fu@intel.com>
> 
> Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able to
> re-allocate surface internally through ff_decode_get_hw_frames_ctx.
> So that hwaccels don't need to reinitialize all hw related configs
> when decode resolution change, just need to re-allocate new surface
> by using new resolution.
> 
> Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> Signed-off-by: Fei Wang <fei.w.wang@intel.com>
> ---
>   libavcodec/decode.c   | 36 ++++++++++++++++++++++++++++++++++++
>   libavcodec/hwconfig.h |  1 +
>   2 files changed, 37 insertions(+)

You can't just not call the user get_format callback and allocate your own surfaces - this breaks direct rendering and other cases where the user wanted to manage the surfaces.

This is also missing any check that the hardware decoder supports the stream post-transition - if the decoder does not support the new size (or any other property of the new stream) then this will try to blindly decode it anyway and fail, where previously it would have correctly fallen back to software decoding.


None of these patches say what the aim is, but from reading them and seeing that VP9 is the intended target then I am guessing that this is intended to support the case where the stream resizes while still using previous reference frames - is that right?

If my guess is correct, I think you should (a) mention that fact in the patches, and (b) target the support at specifically that case, and not try to mess with any other reinit cases.

Something like: if you know you are in that case (the decoder itself has this information and could pass it to ff_get_format somehow) and the context supports it (I am still unclear how this support can be determined - the libva documentation is very clear that a context is tied to a particular height/width), then remember the context across the user get_format call and if things match up then re-use it.

If for some reason you are in that case but it can't work (e.g. because the new size isn't supported by the hardware), then you need a better error message - the stream is actually broken because most frames are not decodable until you reach another recovery point (since the reference frames are in hardware surfaces so the software decoder can't use them).

- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 1/3] lavc/decode: Warp get_hw_config function

[Mark Thompson]

On 07/09/2022 09:47, Xiang, Haihao wrote:
> On Wed, 2022-08-31 at 01:20 +0000, Wang, Fei W wrote:
>> On Tue, 2022-08-23 at 16:19 +0800, Fei Wang wrote:
>>> From: Linjie Fu <linjie.fu@intel.com>
>>>
>>> Wrap the procedure of getting the hardware config from a pixel format
>>> into a function.
>>>
>>> Signed-off-by: Linjie Fu <linjie.fu@intel.com>
>>> Signed-off-by: Fei Wang <fei.w.wang@intel.com>
>>> ---
>>>   libavcodec/decode.c | 31 +++++++++++++++++++------------
>>>   1 file changed, 19 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>>> index 75373989c6..3b69426c09 100644
>>> --- a/libavcodec/decode.c
>>> +++ b/libavcodec/decode.c
>>> @@ -1156,6 +1156,24 @@ static void hwaccel_uninit(AVCodecContext
>>> *avctx)
>>>       av_buffer_unref(&avctx->hw_frames_ctx);
>>>   }
>>>   
>>> +static const AVCodecHWConfigInternal *get_hw_config(AVCodecContext
>>> *avctx, enum AVPixelFormat fmt)
>>> +{
>>> +    const AVCodecHWConfigInternal *hw_config;
>>> +
>>> +    if (!ffcodec(avctx->codec)->hw_configs)
>>> +        return NULL;
>>> +
>>> +    for (int i = 0;; i++) {
>>> +        hw_config = ffcodec(avctx->codec)->hw_configs[i];
>>> +        if (!hw_config)
>>> +            return NULL;
>>> +        if (hw_config->public.pix_fmt == fmt)
>>> +            return hw_config;
>>> +    }
>>> +
>>> +    return NULL;
>>> +}
>>> +
>>>   int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat
>>> *fmt)
>>>   {
>>>       const AVPixFmtDescriptor *desc;
>>> @@ -1213,18 +1231,7 @@ int ff_get_format(AVCodecContext *avctx, const
>>> enum AVPixelFormat *fmt)
>>>               break;
>>>           }
>>>   
>>> -        if (ffcodec(avctx->codec)->hw_configs) {
>>> -            for (i = 0;; i++) {
>>> -                hw_config = ffcodec(avctx->codec)->hw_configs[i];
>>> -                if (!hw_config)
>>> -                    break;
>>> -                if (hw_config->public.pix_fmt == user_choice)
>>> -                    break;
>>> -            }
>>> -        } else {
>>> -            hw_config = NULL;
>>> -        }
>>> -
>>> +        hw_config = get_hw_config(avctx, user_choice);
>>>           if (!hw_config) {
>>>               // No config available, so no extra setup required.
>>>               ret = user_choice;
>>
>> Ping, any more comments on V3?
>>
> 
> The patchset LGTM and works well for me, I'll apply this patchset if no more
> comment.

See <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-September/301124.html>.

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 2/3] lavc/decode: Add internal surface re-allocate method for hwaccel

[Wang, Fei W]

On Wed, 2022-09-07 at 22:56 +0100, Mark Thompson wrote:
> On 23/08/2022 09:19, Fei Wang wrote:
> > From: Linjie Fu <linjie.fu@intel.com>
> > 
> > Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able
> > to
> > re-allocate surface internally through ff_decode_get_hw_frames_ctx.
> > So that hwaccels don't need to reinitialize all hw related configs
> > when decode resolution change, just need to re-allocate new surface
> > by using new resolution.
> > 
> > Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> > Signed-off-by: Fei Wang <fei.w.wang@intel.com>
> > ---
> >   libavcodec/decode.c   | 36 ++++++++++++++++++++++++++++++++++++
> >   libavcodec/hwconfig.h |  1 +
> >   2 files changed, 37 insertions(+)
> 
> You can't just not call the user get_format callback and allocate
> your own surfaces - this breaks direct rendering and other cases
> where the user wanted to manage the surfaces.
> 
> This is also missing any check that the hardware decoder supports the
> stream post-transition - if the decoder does not support the new size
> (or any other property of the new stream) then this will try to
> blindly decode it anyway and fail, where previously it would have
> correctly fallen back to software decoding.
> 
> 
> None of these patches say what the aim is, but from reading them and
> seeing that VP9 is the intended target then I am guessing that this
> is intended to support the case where the stream resizes while still
> using previous reference frames - is that right?

Yes, this fixed some vp9 resize streams which reference frames has
different resolution.

> 
> If my guess is correct, I think you should (a) mention that fact in
> the patches, and (b) target the support at specifically that case,
> and not try to mess with any other reinit cases.
> 
> Something like: if you know you are in that case (the decoder itself
> has this information and could pass it to ff_get_format somehow) and
> the context supports it (I am still unclear how this support can be
> determined - the libva documentation is very clear that a context is
> tied to a particular height/width), then remember the context across
> the user get_format call and if things match up then re-use it.

Thanks, the logic looks good. I will check it later to see if any
blocks on the detail implementation.

Thanks
Fei
> 
> If for some reason you are in that case but it can't work (e.g.
> because the new size isn't supported by the hardware), then you need
> a better error message - the stream is actually broken because most
> frames are not decodable until you reach another recovery point
> (since the reference frames are in hardware surfaces so the software
> decoder can't use them).
> 
> - Mark
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 2/3] lavc/decode: Add internal surface re-allocate method for hwaccel

[Wang, Fei W]

On Mon, 2022-09-19 at 14:08 +0800, Fei Wang wrote:
> On Wed, 2022-09-07 at 22:56 +0100, Mark Thompson wrote:
> > On 23/08/2022 09:19, Fei Wang wrote:
> > > From: Linjie Fu <linjie.fu@intel.com>
> > > 
> > > Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able
> > > to
> > > re-allocate surface internally through
> > > ff_decode_get_hw_frames_ctx.
> > > So that hwaccels don't need to reinitialize all hw related
> > > configs
> > > when decode resolution change, just need to re-allocate new
> > > surface
> > > by using new resolution.
> > > 
> > > Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> > > Signed-off-by: Fei Wang <fei.w.wang@intel.com>
> > > ---
> > >   libavcodec/decode.c   | 36 ++++++++++++++++++++++++++++++++++++
> > >   libavcodec/hwconfig.h |  1 +
> > >   2 files changed, 37 insertions(+)
> > 
> > You can't just not call the user get_format callback and allocate
> > your own surfaces - this breaks direct rendering and other cases
> > where the user wanted to manage the surfaces.
> > 
> > This is also missing any check that the hardware decoder supports
> > the
> > stream post-transition - if the decoder does not support the new
> > size
> > (or any other property of the new stream) then this will try to
> > blindly decode it anyway and fail, where previously it would have
> > correctly fallen back to software decoding.
> > 
> > 
> > None of these patches say what the aim is, but from reading them
> > and
> > seeing that VP9 is the intended target then I am guessing that this
> > is intended to support the case where the stream resizes while
> > still
> > using previous reference frames - is that right?
> 
> Yes, this fixed some vp9 resize streams which reference frames has
> different resolution.
> 
> > If my guess is correct, I think you should (a) mention that fact in
> > the patches, and (b) target the support at specifically that case,
> > and not try to mess with any other reinit cases.
> > 
> > Something like: if you know you are in that case (the decoder
> > itself
> > has this information and could pass it to ff_get_format somehow)
> > and
> > the context supports it (I am still unclear how this support can be
> > determined - the libva documentation is very clear that a context
> > is
> > tied to a particular height/width), then remember the context
> > across
> > the user get_format call and if things match up then re-use it.
> 
> Thanks, the logic looks good. I will check it later to see if any
> blocks on the detail implementation.

Current decode logis is hwaccel->uninit, get_format, hwaccel->init.
While the avctx->internal->hwaccel_priv_data is freed in uninit and
re-alloc in init, so it can't store and re-use vaContext in get_format.

I have modified the other version of V4, which can keep current decode
logic as much as possible and still put alloc surfaces in
hwaccel.init() after call back get_foramt.

Thanks
Fei
> 
> Thanks
> Fei
> > If for some reason you are in that case but it can't work (e.g.
> > because the new size isn't supported by the hardware), then you
> > need
> > a better error message - the stream is actually broken because most
> > frames are not decodable until you reach another recovery point
> > (since the reference frames are in hardware surfaces so the
> > software
> > decoder can't use them).
> > 
> > - Mark
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > 
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".