On 13/04/16 09:14, nablet developer wrote: > >> On 13 Apr 2016, at 14:08, wm4 <nfx...@googlemail.com> wrote: >> >> On Thu, 7 Apr 2016 11:44:20 -0400 >> nablet developer <s...@nablet.com <mailto:s...@nablet.com>> wrote: >> >>> Signed-off-by: nablet developer <s...@nablet.com> >>> --- >>> libavcodec/qsv.c | 64 >>> +++++++++++++++++++++-------------------------- >>> libavcodec/qsv.h | 53 +++++++++++++++++++++++++++++++++++++++ >>> libavcodec/qsv_api.c | 26 +++++++++++++++++++ >>> libavcodec/qsv_internal.h | 15 +---------- >>> libavcodec/qsvdec.c | 13 +++++----- >>> libavcodec/qsvdec.h | 3 ++- >>> libavcodec/qsvenc.c | 16 ++++++------ >>> libavcodec/qsvenc.h | 2 +- >>> 8 files changed, 125 insertions(+), 67 deletions(-) >> >> Why would this API need to be exported? > > previously QuickSync was used only by libavcodec and its components - e.g. > there are QSV encoder and decoders for AVC and MPEG-2. so it was OK that > QuickSync initialisation and cleanup functions were local for libavcodec. > > but right now we're adding QuickSync VPP component to libavfilter, so > mentioned functions now become shared at least between libavcodec and > libavfilter. > therefore, patch to add QSV VPP filter was rejected because it accessed > libavcodec functions which were local, and it was suggested that such > functions are need to be exported from libavcodec, so libavfilter can use > them. >
This is precisely one of the problems that the hwcontext code was designed to solve. I suggest using that rather than adding new ad-hoc codec-specific API calls - make libavutil/hwcontext_qsv.c; it should not require any new API calls at all. As a bonus, it also solves the context propagation problem which you will run into later when combining multiple filter and codec components. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
