[FFmpeg-devel] [PATCH] qsv.c: making qsv session routines common for libavcodec and libavfilter modules.

[wm4]

On Fri, 13 Nov 2015 10:57:59 +0300
Ivan Uskov <ivan.uskov at 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.uskov at 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?