On 24/05/16 12:49, nablet developer wrote: > >> On 24 May 2016, at 17:01, Mark Thompson <s...@jkqxz.net> wrote: >> >> On 13/04/16 09:18, nablet developer wrote: >>> Signed-off-by: nablet developer <s...@nablet.com> >>> --- >>> libavcodec/qsv.c | 35 +--------------------------- >>> libavcodec/qsv_internal.h | 5 ---- >>> libavcodec/qsvdec.c | 1 + >>> libavcodec/qsvenc.c | 1 + >>> libavutil/Makefile | 1 + >>> libavutil/qsv_internal.c | 58 >>> +++++++++++++++++++++++++++++++++++++++++++++++ >>> libavutil/qsv_internal.h | 27 ++++++++++++++++++++++ >>> 7 files changed, 89 insertions(+), 39 deletions(-) >>> create mode 100644 libavutil/qsv_internal.c >>> create mode 100644 libavutil/qsv_internal.h >>> >>> diff --git a/libavutil/qsv_internal.h b/libavutil/qsv_internal.h >>> new file mode 100644 >>> index 0000000..de00d09 >>> --- /dev/null >>> +++ b/libavutil/qsv_internal.h >>> ... >>> +/** >>> + * Convert a libmfx error code into a ffmpeg error code. >>> + */ >>> +int ff_qsv_error(int mfx_err); >> >> This fails for non-static builds because of the namespace prefix (try >> building >> the shared libraries). > > oh, good catch, thanks. I think function then should be called > "avpriv_qsv_error" according to the > https://ffmpeg.org/developer.html#Naming-conventions > <https://ffmpeg.org/developer.html#Naming-conventions>, right?
Correct, assuming this form is accepted. (For example, it could instead be a static inline function and avoid the namespace issue by not appearing as a symbol in the binary. Not sure whether that is actually better, but it is a possibility to consider.) > I will also test my further changes with shared builds starting from now (I > was using instructions from > https://trac.ffmpeg.org/wiki/CompilationGuide/Centos > <https://trac.ffmpeg.org/wiki/CompilationGuide/Centos> which were for static > build). > >> >> Does this function really need to be available everywhere? I think you >> should >> wait until you have other patches which actually require it to so that this >> change can be assessed properly. In isolation, it is not useful. > > hm, if my other patches will depend on this patch, how can they be applied > before this change? I am actually following advice from > https://ffmpeg.org/developer.html#Submitting-patches-1 > <https://ffmpeg.org/developer.html#Submitting-patches-1> to split patches > into small self-contained pieces. please advice how to proceed. I was meaning sending this patch along with others together as a patch series. They are still distinct changes, self-contained in each patch and possible to apply separately in order, but submitted together in order to make the review more meaningful. - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
