On Fri, 13 Nov 2015 10:57:59 +0300 Ivan Uskov <ivan.us...@nablet.com> wrote:
> Hello Hendrik, > > Friday, November 13, 2015, 12:55:38 AM, you wrote: > > HL> On Thu, Nov 12, 2015 at 10:15 PM, Ivan Uskov <ivan.us...@nablet.com> > wrote: > >> Hello All, > >> > >> As it turned out, a suggested recently libavfilter/vf_qsv_vpp.c may not > >> use > >> ff_qsv_init_internal_session() from libavcodec/qsv.c. > >> The attached patch moves qsv.c and qsv_internal.h to libavutil subdir to > >> make > >> corresponded routines common for codecs and filters. > >> First argument of ff_qsv_init_internal_session()has been changed to > >> accept > >> pointer to any context structure compatible with av_log(). > >> > >> Please review. > > HL> Your patch does not work. Please test it with dynamic linking, and > HL> you'll immediately see it failing (hint: only av* symbols are > HL> exported) > Sorry, really released dynamic linking. > Ok, it can be fixed if it will necessary, thank. > > HL> Secondly, I don't think exposing these internals as public API (which > HL> avutil generally is), would be a good idea at all. > HL> Heck the header is even called qsv_internal.h, stuff like this should > HL> never be used across library boundaries. It puts the API/ABI in stone, > HL> and hinders any future expansions or enhancements. > We can rename qsv_internal.h to qsv_common.h it is just question of <legacy> > naming. > The ff_qsv_init_internal_session() can be renamed to > av_init_default_session() > etc and can be used in user application. BTW, the current qsvdec.c example > would to use such API instead direct and non-portable VAAPI-related code > that currently works for linux platforms only. > > HL> avutil is not a place we dump stuff that should be shared between > HL> avcodec and avfilter, or similar, avutil should generally be public > HL> useful API. > I believe 3 of 4 functions here can be published as useful API. > If you do not like this way, could you please advise some another > constructive way to avoid a duplication of more then 300 code lines? Or copy > paste between codecs and filters is really best solution for this case? > Thank! > Didn't we just write how we don't want this to be public API? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
