On 28/05/2019 08:46, Yan Wang wrote:
>
> On 5/28/2019 3:16 PM, Hendrik Leppkes wrote:
>> On Tue, May 28, 2019 at 8:57 AM Yan Wang <yan.w...@linux.intel.com> wrote:
>>> When the format change, the VAAPI context cannot be destroyed.
>>> Otherwise, the reference frame surface will lost.
>>>
>>> Signed-off-by: Yan Wang <yan.w...@linux.intel.com>
>>> ---
>>> libavcodec/decode.c | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>>> index 6c31166ec2..3eda1dc42c 100644
>>> --- a/libavcodec/decode.c
>>> +++ b/libavcodec/decode.c
>>> @@ -1397,7 +1397,9 @@ int ff_get_format(AVCodecContext *avctx, const enum
>>> AVPixelFormat *fmt)
>>>
>>> for (;;) {
>>> // Remove the previous hwaccel, if there was one.
>>> +#if !CONFIG_VP9_VAAPI_HWACCEL
>>> hwaccel_uninit(avctx);
>>> +#endif
>>>
>>> user_choice = avctx->get_format(avctx, choices);
>>> if (user_choice == AV_PIX_FMT_NONE) {
>>> @@ -1479,7 +1481,11 @@ int ff_get_format(AVCodecContext *avctx, const enum
>>> AVPixelFormat *fmt)
>>> "missing configuration.\n", desc->name);
>>> goto try_again;
>>> }
>>> +#if CONFIG_VP9_VAAPI_HWACCEL
>>> + if (hw_config->hwaccel && !avctx->hwaccel) {
>>> +#else
>>> if (hw_config->hwaccel) {
>>> +#endif
>>> av_log(avctx, AV_LOG_DEBUG, "Format %s requires hwaccel "
>>> "initialisation.\n", desc->name);
>>> err = hwaccel_init(avctx, hw_config);
>>> --
>>> 2.17.2
>>>
>> This change feels just wrong. First of all, preprocessors are
>> absolutely the wrong way to go about this.
>
> Sorry for this. I am new guy for ffmpeg development. What way should be
>
> better? I can refine it.
>
>> Secondly, if the frames need to change size, or surface format, then
>> this absolutely needs to be called, doesn't it?
>
> Based on VP9 spec, the frame resolution can be changed per frame. But current
>
> frame will need refer to previous frame still. So if destroy the VAAPI
> context, it
>
> will cause reference frame surface in VAAPI driver lost.
>
> In fact, this patch is for the issue:
>
> https://github.com/intel/media-driver/issues/629
>
> its 2nd frame (128x128) will refer to the 1st frame (256x256).
Can you explain exactly what is going wrong here? The surface is definitely
still present - the reference frame list entry holds a reference to it.
- 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-requ...@ffmpeg.org with subject "unsubscribe".
