[FFmpeg-devel] ffmpeg improvement for x265

[Reimar Döffinger]

On Tue, Dec 30, 2014 at 10:31:14AM +0100, wm4 wrote:
> On Tue, 30 Dec 2014 13:38:00 +0800 (CST)
> llj <liu_liujun at 126.com> wrote:
> 
> > hello,
> > My name is Liujun Liu, a developer of x265 group.
> > firstly I want to describe what the problem is. There is an option HI_BIT_DEPTH in x265 CMake build option, this is for 10 bits video encoder, by default this option is off, so it encodes video as 8 bits precision(even there is command line to force encode as 10 bits, but the precision is only 0~255). however, we want to make it 
> > also possible for real 10 bits video encoding in one ffmpeg build, so what we expect is that the user build two x265 share libraries, one is 8bit, called libx265, the other is libx265_10, they have the same API,  the ffmpeg can invoke either one dynamically by the command line option --profile main10 is added or not(default is main), so is that possible for me to submit a patch to ffmpeg to let it dynamic invoke the x265 share library.
> > 
> > 
> > if it is get the approval, can you give me some advices by how to change it in a good way because I'm a newer for ffmpeg. 
> 
> Wouldn't it be better to have libx265 dispatch between 8 bit and 10
> bit, instead of requiring every single user to do the dynamic library
> loading dance?

Strongly agree.
dlopen can also be used to defeat protection measures like address space
randomization and also negatively impacts .relro, textrels etc..
An API that can only work with dlopen is a horrible idea, both for
convenience and due to security concerns.
Not to mention the whole mess you get into if you are trying to use the
8 bit library, but another library you use loads the 10 bit version.
I'd bet this design will lead to nice random crashes as ll libraries
(including libx265 itself depending on compiler options/OS) now randomly
call functions from either the one or the other.
So I'll actually change my vote to "let's not even try to support such
a braindead idea".