Bug#667573: x264: 10 bit builds

[Sebastian Dröge]

On Mi, 2013-01-16 at 15:46 +0100, Nicolas George wrote:
> Le septidi 27 nivôse, an CCXXI, Sebastian Dröge a écrit :
> > I don't think this change makes sense as is. x264 built with 10 bit
> > support does not accept raw 8 bit video and vice versa (and has to be
> > configured differently), and x264 build with 10 bit support does only
> > support different h264 profiles than the 8 bit version.
> 
> That is true, but that is for the calling application to worry.

Right, but the calling application has no way to know what the library
will accept other than looking at x264_config.h.

> >							  And these 10 bit
> > profiles are usually not supported by hardware decoders.
> 
> That is for the users to decide, this is not a choice a packager is entitled
> to impose.

Yes, and that's exactly why it is important to know inside the
application what x264 will be able to output. Which again is only
possible by looking at x264enc_config.h.

> > Software currently uses the #defines in x264_config.h to get the
> > capabilities of the library at build time. If suddenly the library gets
> > replaced by one with different build parameters, software will stop
> > working correctly because of that.
> 
> That is not true. I can not vouch for all applications out there, but I can
> confirm that the most important one works perfectly well under these
> circumstances.

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.

Which again, is only possible by looking at x264enc_config.h.

> > Ideally x264 would allow using different bit depths in the same build,
> 
> This world is not perfect.

True, but that's no reason to make it worse.

> > or at least a different soname should be used for the resulting library.
> 
> That would prevent changing the library at run time with just an environment
> variable, as has already been stated.

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.
-------------- 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://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20130116/58937b9c/attachment.pgp>