[x264-devel] Bug#667573: Bug#667573: x264: 10 bit builds

[Sebastian Dröge]

On Do, 2013-01-17 at 10:29 -0800, Jason Garrett-Glaser wrote:
> On Wed, Jan 16, 2013 at 7:59 AM, Sebastian Dröge
> <slomo at circular-chaos.org> wrote:
> > On Mi, 2013-01-16 at 16:45 +0100, Nicolas George wrote:
> >> Le septidi 27 nivôse, an CCXXI, Sebastian Dröge a écrit :
> >> > Right, but the calling application has no way to know what the library
> >> > will accept other than looking at x264_config.h.
> >>
> >> That is not true:
> >>
> >> /* x264_bit_depth:
> >>  *      Specifies the number of bits per pixel that x264 uses. This is also the
> >>  *      bit depth that x264 encodes in. If this value is > 8, x264 will read
> >>  *      two bytes of input data for each pixel sample, and expect the upper
> >>  *      (16-x264_bit_depth) bits to be zero.
> >>  *      Note: The flag X264_CSP_HIGH_DEPTH must be used to specify the
> >>  *      colorspace depth as well. */
> >> X264_API extern const int x264_bit_depth;
> >
> > Thanks, I missed these two in the documentation. FWIW, what's the point
> > of defining them in x264_config.h too then?
> 
> People seemed to like the idea of having both.  If I had to guess,
> accessing x264_bit_depth would require running a test program, which
> isn't possible if you're cross-compiling.

Yeah but instead of checking this during compile time it would make more
sense to do it during runtime. Otherwise the "replace-library" hack
won't work again to switch between 8 bit and 10 bit builds.


Btw, what's the reason for making it a compile time parameter and not
allowing to handle 8/9/10 bit from the same library build?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20130117/cbbb3b7f/attachment.pgp>