Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
On Wed, Jan 16, 2013 at 7:59 AM, Sebastian Dröge sl...@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. Jason ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
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 sl...@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? signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
On Thu, Jan 17, 2013 at 10:48 AM, Sebastian Dröge sl...@circular-chaos.org wrote: 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 sl...@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? The main reason is that 8-bit vs 8-bit requires changing the pixel format from 8-bit to 16-bit. This requires basically completely changing all pointer calculations in all of x264. It's possible to handle this at runtime; libav does. Here's what you have to do: 1. Rename all bit-depth-specific asm functions and the like to avoid collisions, then runtime-load the correct ones. 2. Make all pixel pointers uint8_t* and manually add a shift factor to every single address calculation in all of x264. 3. Template all functions where 2) introduces a significant performance impact (probably most of the core analysis loop). It's icky, a lot of work, and most importantly, nobody's done it. The original patch simply changed variable types from uint8_t to pixel (and lots of similar compile-time templating bits), which was already enough work to be an entire GSOC project. libav does things at runtime, but it also does 1-2 orders of magnitude less address calculation and is generally way simpler (after all, it's a decoder, not an encoder). It needs almost zero addressing outside of DSP functions; see how relatively little pixel_shift shows up in h264.c. Jason ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
On Di, 2013-01-15 at 22:03 +, Debian Bug Tracking System wrote: [...] [ Reinhard Tartler ] * Build both 8bit and 10bit versions of libx264, Closes: #667573 [...] Hi, 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. And these 10 bit profiles are usually not supported by hardware decoders. 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. Ideally x264 would allow using different bit depths in the same build, or at least a different soname should be used for the resulting library. signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
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. 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. 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. Ideally x264 would allow using different bit depths in the same build, This world is not perfect. 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. Regards, -- Nicolas George signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
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. signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
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; 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. Which again, is only possible by looking at x264enc_config.h. And again, this is not true. True, but that's no reason to make it worse. Thanks for your support. 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. Regards, -- Nicolas George signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
Le septidi 27 nivôse, an CCXXI, Sebastian Dröge a écrit : Thanks, I missed these two in the documentation. FWIW, what's the point of defining them in x264_config.h too then? You would have to ask that from the x264 developers. 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. What are we talking about exactly? My policy, on systems that I handle, is to install the 16 bits variant in a separate directory not in the library search path, with the same SONAME, so that users can get their applications to use it by setting LD_LIBRARY_PATH. I thought this was the topic here. Users who play with LD_LIBRARY_PATH are responsible for what they are doing, especially checking that the applications are compatible with the redirected library. Regards, -- Nicolas George signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
On 10/14/12 21:56, Reinhard Tartler wrote: Something like this commit should do the trick: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/x264.git;a=commitdiff;h=ceab497a30560db9db7bf6ded594400f76a2686a This is not finished, though. It still needs documentation in README.Debian. I'm also thinking about included a wrapper script that sets LD_LIBRARY_PATH. And it is of course totally untested, so feedback more than welcome. I've built this package and can confirm that the library works using a dlopen() approach. I was wondering about pkg-config support for the 10 bit library, a second .pc file looks like it could come from a bit of search/replace on the original. Regards, Jonathan. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
Am 17.10.2012 10:09, schrieb Jonathan Rosser: I've built this package and can confirm that the library works using a dlopen() approach. I've seen Reinhard has already implemented this in the Debian package, so it merely needs to get documented properly. Thanks! I was wondering about pkg-config support for the 10 bit library, a second .pc file looks like it could come from a bit of search/replace on the original. Aren't the 8bit and 10bit libraries ABI- and API-compatible? Then one could build against the 8bit-variant and load the 10bit-variant at run-time with a LD_LIBRARY_PATH hack. Thus we wouldn't need a second pkg-config file. Or are we talking about static linking here? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
On Wed, Oct 17, 2012 at 10:25 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 17.10.2012 10:09, schrieb Jonathan Rosser: I've built this package and can confirm that the library works using a dlopen() approach. I've seen Reinhard has already implemented this in the Debian package, so it merely needs to get documented properly. Thanks! Yeah, and perhaps a wrapper script, which should then get properly documented. I was wondering about pkg-config support for the 10 bit library, a second .pc file looks like it could come from a bit of search/replace on the original. Aren't the 8bit and 10bit libraries ABI- and API-compatible? Then one could build against the 8bit-variant and load the 10bit-variant at run-time with a LD_LIBRARY_PATH hack. Thus we wouldn't need a second pkg-config file. The fact that Jonathan confirms that dlopen()'ing the second library works confirms that both libraries are ABI compatible for practical reasons. Jonathan, what problem would a 2nd pkg-config file solve? Or are we talking about static linking here? I am not convinced that we should invest any effort in supporting static linking in the Debian x264 package. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
On 10/17/12 09:28, Reinhard Tartler wrote: The fact that Jonathan confirms that dlopen()'ing the second library works confirms that both libraries are ABI compatible for practical reasons. Jonathan, what problem would a 2nd pkg-config file solve? There were a few things that were in my mind, primarily around writing portable code: * Detect the presence of the 10 bit version in a configure.ac (the version number won't tell you this) * Retrieve the location to dlopen() from (will every distro put it in the same place?) Anyway - maybe I'm getting ahead of myself and simply having the 10 bit version available is good enough. I'm very happy that it now builds in the official package. Regards, Jon. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
Am 17.10.2012 10:28, schrieb Reinhard Tartler: I am not convinced that we should invest any effort in supporting static linking in the Debian x264 package. But we do provide a static library in libx264-dev? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
On Wed, Oct 17, 2012 at 10:42 AM, Jonathan Rosser jonathan.ros...@rd.bbc.co.uk wrote: On 10/17/12 09:28, Reinhard Tartler wrote: The fact that Jonathan confirms that dlopen()'ing the second library works confirms that both libraries are ABI compatible for practical reasons. Jonathan, what problem would a 2nd pkg-config file solve? There were a few things that were in my mind, primarily around writing portable code: * Detect the presence of the 10 bit version in a configure.ac (the version number won't tell you this) How is pkg-config supposed to tell you this? * Retrieve the location to dlopen() from (will every distro put it in the same place?) Also, out of scope of pkg-config IMO. Could be implemented, but would only make sense if you convinced upstream to do this so that consistency across distribution is maintained Anyway - maybe I'm getting ahead of myself and simply having the 10 bit version available is good enough. I'm very happy that it now builds in the official package. OK. Thanks for your comments. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
On Wed, Oct 17, 2012 at 11:10 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 17.10.2012 10:28, schrieb Reinhard Tartler: I am not convinced that we should invest any effort in supporting static linking in the Debian x264 package. But we do provide a static library in libx264-dev? Even removing the .a file would be effort IMO ;-) - I would do that as soon as some issue with it comes up. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
On 13/10/12 04:59, Reinhard Tartler wrote: Oh I see what you did there. I don't think that's gonna work in debian. TBH, I think we should just install the 10 bit libx264.so binary into the regular libx264-NN package and document it properly in ./usr/share/doc/libx264-NN/README.Debian. On the second thought, we could even install some wrapper into /usr/bin that starts the passed on argument with proper LD_LIBRARY_PATH. In any case, I don't see the point in adding new source or binary packages. Trouble is, when you do a 10 bit build you end up with a library of the same name and installing to the same location as the 8 bit one. I'm no expert on the debian packaging, but I could not see a way of renaming the 10 bit .so (dh_install won't do it). There might well be a neat way of achieving this. You have to re-run the configure script with different options to create the 10 bit version, and that's well beyond what I know how to do in the rules file. Regards, Jonathan. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
Am 12.10.2012 04:41, schrieb Reinhard Tartler: That's indeed something that I could do in the Debian package: Install a regular libx264.so in /usr/lib, and a 10bit in /usr/lib/x264-10bit/libx264.so in addition, and document how to use it in some README.Debian file. Not really nice, but I guess better than nothing. How about Debian's alternatives system? I think it is easier to use and more consistent than a LD_LIBRARY_PATH hack. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
Le primidi 21 vendémiaire, an CCXXI, Fabian Greffrath a écrit : How about Debian's alternatives system? I think it is easier to use and more consistent than a LD_LIBRARY_PATH hack. AFAIK, the alternative system requires root privileges to change the selected alternative, whereas LD_LIBRARY_PATH can be changed by any user on a per-encode basis. Several encodes can be started with different LD_LIBRARY_PATH, and therefore different bit depth. The only limitation with that system is that a single process is limited to a single bit depth. Of course, the alternative system could be used on top of that, to allow to configure the default bit depth, when no LD_LIBRARY_PATH is specified. Regards, -- Nicolas George ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
On 10/11/12 21:07, Jason Garrett-Glaser wrote: Would dlopen() work to hack around this sort of limitation? I recall seeing a hack for x264cli that allowed both 8-bit and 10-bit encoding by doing this. Jason Certainly a dlopen() approach works adequately for me now. It is just that my approach to generating an installable package is ugly. I had considered two different approaches, 1) Install a parallel build of x264 in a new directory hierarchy and knowing that path, open the .so with dlopen(). 2) Try to modify the configure scripts and makefile to in order to produce libx264-10bit.so that could be placed in the usual install location alongside the 8 bit version. The name of the built libraries could be controlled by a configure option. You would still need a dlopen() based approach in some cases but the location of the library would no need to be specified. I ended up doing 1) simply because it was easier, but I feel that 2) might actually be a better solution, as everything could live in standard locations. Regards, Jonathan. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
On 10/12/12 09:15, Nicolas George wrote: Le primidi 21 vendémiaire, an CCXXI, Fabian Greffrath a écrit : How about Debian's alternatives system? I think it is easier to use and more consistent than a LD_LIBRARY_PATH hack. AFAIK, the alternative system requires root privileges to change the selected alternative, whereas LD_LIBRARY_PATH can be changed by any user on a per-encode basis. Several encodes can be started with different LD_LIBRARY_PATH, and therefore different bit depth. The only limitation with that system is that a single process is limited to a single bit depth. Of course, the alternative system could be used on top of that, to allow to configure the default bit depth, when no LD_LIBRARY_PATH is specified. I agree. There are different cases here, mine was the most complex where I need to decide at runtime if 8 or 10 bit was needed. As others have said this can be achieved by using a suitable arrangement of dlopen() to select the required library. From a debian packaging point of view, the key thing is what is the correct way to package up and install the 10 bit version alongside the 8 bit. From an x264 perspective, is there anything that needs to be done to the build system to support this in a clean way. Regards, Jonathan. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
On Fri, Oct 12, 2012 at 2:21 AM, Jonathan Rosser jonathan.ros...@rd.bbc.co.uk wrote: Here is my somewhat incomplete attempt at doing just that. It was more involved than I expected. https://github.com/jrosser/x264-10bit-deb Oh I see what you did there. I don't think that's gonna work in debian. TBH, I think we should just install the 10 bit libx264.so binary into the regular libx264-NN package and document it properly in ./usr/share/doc/libx264-NN/README.Debian. On the second thought, we could even install some wrapper into /usr/bin that starts the passed on argument with proper LD_LIBRARY_PATH. In any case, I don't see the point in adding new source or binary packages. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
It would be really good to get a proper solution to this. I currently require 8 bit and 10bit of x264 to be available to the same application at the same time. A typical use case would be simultaneously encoding 10bit 4:2:2 and 8 bit 4:2:0 versions of the same source video, this cannot be achieved with linkage to a single x264 library. [Alternatively an application that can encode in either 8 or 10 bit modes is equally difficult to write] I have resorted to building my own custom .deb for the 10 bit version which installs to /usr/x264-10bit/... then a plug-in architecture and dlopen() allow one executable to dynamically link against both the 8 and 10bit versions and keep both sets of symbols isolated from each other. This is all fairly horrible, but works I don't see the 8 or 10 bit versions as been alternatives (overloaded terminology, sorry!), I need them to be able to co-exist. Anyway, just some input to help define what might be useful for a 10bit x264 package. Jonathan Rosser Lead Research Engineer BBC Research Development ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
tags 667573 upstream forwarded 667573 x264-de...@videolan.org severity 667573 wishlist stop Dear x264 developers, The following quote is taken from a debian bug report that has been filed against the debian x264 package. The full buglog can be read at http://bugs.debian.org/667573 On Thu, Oct 11, 2012 at 2:55 AM, Jonathan Rosser jonathan.ros...@rd.bbc.co.uk wrote: It would be really good to get a proper solution to this. I currently require 8 bit and 10bit of x264 to be available to the same application at the same time. A typical use case would be simultaneously encoding 10bit 4:2:2 and 8 bit 4:2:0 versions of the same source video, this cannot be achieved with linkage to a single x264 library. [Alternatively an application that can encode in either 8 or 10 bit modes is equally difficult to write] I have resorted to building my own custom .deb for the 10 bit version which installs to /usr/x264-10bit/... then a plug-in architecture and dlopen() allow one executable to dynamically link against both the 8 and 10bit versions and keep both sets of symbols isolated from each other. This is all fairly hohrrible, but works I don't see the 8 or 10 bit versions as been alternatives (overloaded terminology, sorry!), I need them to be able to co-exist. Anyway, just some input to help define what might be useful for a 10bit x264 package. Thanks for your bug report. Unfortunately, I don't see a good way how we can provide this functionality cleanly in Debian without the help of upstream. I understand that the 10bit implementation uses a lot of CPP magic to reuse a lot of code, but to me the sanest solution to this problem seems to me to compile twice. Is there any way to make the libx264.so library provide both 8bit and 10bit encoding? Jonathan, until tihs is resolved, I would suggest you to compiled x264 as static library and link your applications against that build. Inconvenient, but I don't see a better solution right now. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Bug#667573: x264: 10 bit builds
Processing commands for cont...@bugs.debian.org: tags 667573 upstream Bug #667573 [x264] x264: 10 bit builds Added tag(s) upstream. forwarded 667573 x264-de...@videolan.org Bug #667573 [x264] x264: 10 bit builds Set Bug forwarded-to-address to 'x264-de...@videolan.org'. severity 667573 wishlist Bug #667573 [x264] x264: 10 bit builds Ignoring request to change severity of Bug 667573 to the same value. stop Stopping processing here. Please contact me if you need assistance. -- 667573: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667573 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
On Thu, Oct 11, 2012 at 9:46 AM, Reinhard Tartler siret...@gmail.com wrote: tags 667573 upstream forwarded 667573 x264-de...@videolan.org severity 667573 wishlist stop Dear x264 developers, The following quote is taken from a debian bug report that has been filed against the debian x264 package. The full buglog can be read at http://bugs.debian.org/667573 On Thu, Oct 11, 2012 at 2:55 AM, Jonathan Rosser jonathan.ros...@rd.bbc.co.uk wrote: It would be really good to get a proper solution to this. I currently require 8 bit and 10bit of x264 to be available to the same application at the same time. A typical use case would be simultaneously encoding 10bit 4:2:2 and 8 bit 4:2:0 versions of the same source video, this cannot be achieved with linkage to a single x264 library. [Alternatively an application that can encode in either 8 or 10 bit modes is equally difficult to write] I have resorted to building my own custom .deb for the 10 bit version which installs to /usr/x264-10bit/... then a plug-in architecture and dlopen() allow one executable to dynamically link against both the 8 and 10bit versions and keep both sets of symbols isolated from each other. This is all fairly hohrrible, but works I don't see the 8 or 10 bit versions as been alternatives (overloaded terminology, sorry!), I need them to be able to co-exist. Anyway, just some input to help define what might be useful for a 10bit x264 package. Thanks for your bug report. Unfortunately, I don't see a good way how we can provide this functionality cleanly in Debian without the help of upstream. I understand that the 10bit implementation uses a lot of CPP magic to reuse a lot of code, but to me the sanest solution to this problem seems to me to compile twice. Is there any way to make the libx264.so library provide both 8bit and 10bit encoding? It'd be very difficult to do this; we'd effectively have to version every single symbol so that they don't collide, then template all the appropriate code. It'd be a lot of work and I don't know anyone willing to do it. Jonathan, until tihs is resolved, I would suggest you to compiled x264 as static library and link your applications against that build. Inconvenient, but I don't see a better solution right now. Would dlopen() work to hack around this sort of limitation? I recall seeing a hack for x264cli that allowed both 8-bit and 10-bit encoding by doing this. Jason ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
Le decadi 20 vendémiaire, an CCXXI, Jason Garrett-Glaser a écrit : Would dlopen() work to hack around this sort of limitation? I recall seeing a hack for x264cli that allowed both 8-bit and 10-bit encoding by doing this. I do not know about x264cli, but I can confirm that if ffmpeg is dynamically linked with libx264.so.$version, then using LD_LIBRARY_PATH to control which build is loaded allows to select between 8-bits and 10-bits at run-time. Regards, -- Nicolas George signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
On 11/10/12 21:07, Jason Garrett-Glaser wrote: It'd be very difficult to do this; we'd effectively have to version every single symbol so that they don't collide, then template all the appropriate code. It'd be a lot of work and I don't know anyone willing to do it. Indeed - that would be a mammoth task. Jonathan, until tihs is resolved, I would suggest you to compiled x264 as static library and link your applications against that build. Inconvenient, but I don't see a better solution right now. Would dlopen() work to hack around this sort of limitation? I recall seeing a hack for x264cli that allowed both 8-bit and 10-bit encoding by doing this. I'm doing a dlopen() trick now and it works very well for my case. The reason I replied to the original Debian bug report is that I consider what I've done to be a bit of an ugly hack. (My packages install a parallel version of x264 into /usr/x264-10bit/). It would be good to come up with a way of installing the 8 and 10 bit versions properly alongside each other. I had considered modifying the configure script to allow the name of the built libraries to be changed via a configure flag. I'd have provided an alternative name for the 10 bit build. Anyway - It is interesting to consider what the right thing to do is, and how applications that want to do 8 or 10 bit interchangeably should be constructed. Regards, Jonathan. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#667573: x264: 10 bit builds
Package: x264 Version: 2:0.120.2171+git01f7a33-3 Severity: wishlist Reporting this to open discussion on this. It looks like 10 bit h264 encoding is becoming the norm. We should allow some way to support both 10 bit and 8 bit builds of x264, possibly making use of the alternatives system. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages x264 depends on: ii libavcodec-extra-53 5:0.8.1-4 ii libavformat-extra-53 4:0.8~beta2.2 ii libavformat53 [libavformat-extra-53] 5:0.8.1-4 ii libavutil-extra-514:0.8.0.1+b1 ii libavutil51 [libavutil-extra-51] 5:0.8.1-4 ii libc6 2.13-27 ii libffms2-22.17-1 ii libpostproc-extra-52 4:0.8~beta2.2 ii libpostproc52 [libpostproc-extra-52] 5:0.8.1-4 ii libswscale-extra-24:0.8~beta2.2 ii libswscale2 [libswscale-extra-2] 5:0.8.1-4 ii libx264-120 2:0.120.2171+git01f7a33-3 ii zlib1g1:1.2.6.dfsg-2 x264 recommends no packages. x264 suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
