On 23/04/18 08:22, Song, Ruiling wrote: >> -----Original Message----- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of >> Mark Thompson >> Sent: Sunday, April 22, 2018 3:21 AM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: make overlay_qsv work based >> on framesync >> >> On 03/04/18 02:50, Ruiling Song wrote: >>> The existing version which was cherry-picked from Libav does not work >>> with FFmpeg framework, because ff_request_frame() was totally >>> different between Libav (recursive) and FFmpeg (non-recursive). >>> The existing overlay_qsv implementation depends on the recursive version >>> of ff_request_frame to trigger immediate call to request_frame() on input >>> pad. >>> But this has been removed in FFmpeg since "lavfi: make request_frame() non- >> recursive." >>> Now that we have handy framesync support in FFmpeg, so I make it work >>> based on framesync. Some other fixing which is also needed to make >>> overlay_qsv work are put in a separate patch. >>> >>> v2: >>> add .preinit field to initilize framesync options. >>> export more options like vf_overlay.c >>> >>> Signed-off-by: Ruiling Song <ruiling.s...@intel.com> >>> --- >>> libavfilter/Makefile | 2 +- >>> libavfilter/vf_overlay_qsv.c | 213 >>> ++++++++++++++++--------------------------- >>> 2 files changed, 78 insertions(+), 137 deletions(-) >>> >> On 03/04/18 02:50, Ruiling Song wrote: >>> For filters based on framesync, the input frame was managed >>> by framesync, so we should not directly keep and destroy it, >>> instead we make a clone of it here, or else double-free will occur. >>> But for other filters not based on framesync, we still need to >>> free the input frame inside filter_frame. That's why I made >>> this v2 to fix the side-effect on normal filters. >>> >>> v2: >>> and one av_frame_free() in vf_vpp_qsv.c >>> >>> Signed-off-by: Ruiling Song <ruiling.s...@intel.com> >>> --- >>> libavfilter/qsvvpp.c | 4 ++-- >>> libavfilter/vf_vpp_qsv.c | 5 ++++- >>> 2 files changed, 6 insertions(+), 3 deletions(-) >> >> Tested, LGTM, set applied with one minor merge fixup - it collided with the >> change to pass through unmodified frames directly. (Apologies for the >> delay!) >> >> Shall I apply this to the 4.0 branch as well? > > Sure, I think it's better to merge to 4.0. I noticed this feature was > included in the release note.
Ok, I've cherry-picked it to the 4.0 branch as well. Thanks, - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel