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.
signature.asc
Description: This is a digitally signed message part
