[x264-devel] Bug#667573: x264: 10 bit builds
Sebastian Dröge
slomo at circular-chaos.org
Wed Jan 16 16:59:32 CET 2013
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?
> > One example of this is the GStreamer x264 plugin. It has to know
> > beforehand which raw video formats are supported and also what the
> > library will output.
>
> AFAICS, gstreamer x264 plugin does not worry about bit depth _at all_. That
> is not a good example.
Well, it does nowadays. I'll change it to use the values from the
library instead of the #defines from x264_config.h then.
> > Yes, and as stated above changed the library at runtime is a bad idea
> > because the library will be different from what the application saw
> > during build it x264_config.h.
>
> If the application is correctly written, it works perfectly (I have done it
> dozens of times) and is very useful. Calling something that works and is
> useful a "bad idea" is a rather unusual use of the expression.
It is a bad idea under the assumptions I had before, and is still a bad
idea without checking first if there is any code in Debian actually
using the values from x264_config.h instead.
It should at least be made more explicit in the documentation that these
two variables (x264_bit_depth and x264_chroma_format) must be checked
and that their equivalents in x264_config.h are completely irrelevant
and must not be used.
-------------- 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/20130116/a5053321/attachment.pgp>
More information about the x264-devel
mailing list