On 07/06/2024 18:48, Lynne wrote:
> On 07/06/2024 17:22, Wu, Tong1 wrote:
>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Lynne
>>> via ffmpeg-devel
>>> Sent: Friday, June 7, 2024 11:10 PM
>>> To: ffmpeg-devel@ffmpeg.org
>>> Cc: Lynne <dev@lynne.ee>
>>> Subject: Re: [FFmpeg-devel] [PATCH v13 06/15] avcodec/vaapi_encode: move
>>> the dpb logic from VAAPI to base layer
>>>
>>> On 03/06/2024 11:18, tong1.wu-at-intel.com@ffmpeg.org wrote:
>>>> From: Tong Wu <tong1.wu@intel.com>
>>>>
>>>> Move receive_packet function to base. This requires adding *alloc,
>>>> *issue, *output, *free as hardware callbacks. HWBaseEncodePicture is
>>>> introduced as the base layer structure. The related parameters in
>>>> VAAPIEncodeContext are also extracted to HWBaseEncodeContext. Then DPB
>>>> management logic can be fully extracted to base layer as-is.
>>>>
>>>> Signed-off-by: Tong Wu <tong1.wu@intel.com>
>>>> ---
>>>>    libavcodec/Makefile             |   2 +-
>>>>    libavcodec/hw_base_encode.c     | 594 ++++++++++++++++++++++++
>>>>    libavcodec/hw_base_encode.h     | 124 +++++
>>>>    libavcodec/vaapi_encode.c       | 793 +++++ 
>>>> ---------------------------
>>>>    libavcodec/vaapi_encode.h       | 102 +---
>>>>    libavcodec/vaapi_encode_av1.c   |  35 +-
>>>>    libavcodec/vaapi_encode_h264.c  |  84 ++--
>>>>    libavcodec/vaapi_encode_h265.c  |  53 ++-
>>>>    libavcodec/vaapi_encode_mjpeg.c |  13 +-
>>>>    libavcodec/vaapi_encode_mpeg2.c |  33 +-
>>>>    libavcodec/vaapi_encode_vp8.c   |  18 +-
>>>>    libavcodec/vaapi_encode_vp9.c   |  24 +-
>>>>    12 files changed, 985 insertions(+), 890 deletions(-)
>>>>    create mode 100644 libavcodec/hw_base_encode.c
>>>
>>> This patch doesn't apply,
>>>
>>> error: sha1 information is lacking or useless (libavcodec/ 
>>> hw_base_encode.c).
>>> error: could not build fake ancestor
>>>
>>> Could you resent the patchset or link me a repo so I can work with it?
>>
>> https://github.com/intel-media-ci/ffmpeg/pull/689 This is the same as 
>> v13 please have a try.
> 
> That worked, thanks.

I don't think the behaviour is correct when the encoding length is less 
than the decode delay. In my old Vulkan code, I had this piece of code 
in the initialization function:

 > if (!src) {
 >     ctx->end_of_stream = 1;
 >     /* Fix timestamps if we hit end-of-stream before the initial
 >      * decode delay has elapsed. */
 >     if (ctx->input_order < ctx->decode_delay)
 >         ctx->dts_pts_diff = ctx->pic_end->pts - ctx->first_pts;
 >     return AVERROR_EOF;
 > }

I think a flush function should be added, to be called by each encoder, 
to make sure the timestamps remain correct.

Also, the D3D12VA structures need an FF prefix, e.g.
D3D12VAEncodeContext -> FFD3D12VAEncodeContext.