Yesterday I was talking with siretart on #xine about the lack of coordination between distributions when it comes to xine packages. Beside him and me, there aren’t many packagers writing on xine-devel, and even between us it is often difficult to coordinate, for instance we talked just yesterday that Debian is not using external libraries, as their policy would be, probably because when the control files were written there was no support for using them. As I’ve changed this for a while now – needing the same in Gentoo – it will now switch to use external whenever possible.
Talking of that, I decided to take a look to FreeBSD ports, renown for not submitting the patches to upstream whatever upstream it is, to see if they had any useful fix to merge. Beside a ton of fixes for FreeBSD 4, quite invasive because they need all the PRId64 and similar macros defined manually, that I’m not going to merge also because they involve crippling a lot of FFmpeg code, I’ve seen a couple of interesting and maybe useful things.
One was a fix for the OSS driver to work on 64-bit FreeBSD systems, as the second parameter (request) of ioctl() function is unsigned long typed rather than int, and there was a temporary used that had the wrong sign. The patch for that was quite invasive and ended up changing a lot of variables from int to long, even some that were passed to the further parameters of ioctl() (which expected them to be int*); the reported problem was fixed, but more likely problems were introduced. I ended up cleaning this patch up first using a __FreeBSD__ conditional, and afterward checking the type of the request parameter during configure stage (and for who’s interested, modern Linux ioctl() also uses unsigned long for the request parameter.. I’m not sure how this didn’t cause problems on 64-bit systems, probably Linux doesn’t use the MSB, so there is no overflow, and sign extension on call; the manpage is wrong on this).
the other set of interesting patches was to add support for Real binary codecs to FreeBSD. I say interesting even if I don’t like binary codecs, I never used them before, and I will probably not use them anymore in the future beside from testing purposes. The reason why I was interested in these was that the Real binary codecs plugins (two of them, for some reason, one for audio and one for video) were being built on every system, without way to disable them, even if they are totally 64-bit unsafe.
I decided this was a good start for cleaning that up. I first started looking to share as much code as possible between the two plugins, so that even merging the two plugins would be possible (working on that right now). Then I put the extra symbols needed for FreeBSD on it.. but I didn’t like the approach of just fake stderr and __environ symbols as it was, so I decided to make them weak aliases to the symbols used in FreeBSD.
As this was far from extensible, though, I ended up, during the night, writing some configure checks so that if the symbols are not found, one by one, they get get weak-aliased with the nearest approximation. I find that autoconf check quite nice, as it allows me to do the minimum checks needed.. when running on GNU/Linux (not sure uclibc/Linux) only the checks for the strict needed symbols are linked, they all pass, and nothing else is tested.
Now, this covers FreeBSD support, but I started this entry talking about 64-bit. Well, when I was looking at the Real plugins themselves, I decided to see how MPlayer fixed the problem with 64-bit.. copied their code, and tested it.. it worked fine.
This means that 1.1.5 release will have AMD64 Real binary codecs support (as well as Alpha) in an improvde real plugin. For Gentoo users, I’ll see to provide a xine-lib snapshot soon, as I need to flesh out a few details with the ebuild, as I changed a few --enable/--disable parameters to --with/--without again, and added an --enable/--disable for real too, so that it’s not build if you don’t want it or can’t run it (we don’t have the Real PPC or Alpha codecs in Gentoo, so the only arches where the real useflag would be used would be x86 and amd64).
So basically the changes coming yesterday are useful for both who wants to use the Real binary codecs and for who doesn’t want to, the first class of users will have a cleaner Real plugin which just works even for Real Audio (instead of failing miserably because FFmpeg tries to take priority over the Real Audio decoder), and one less plugin to load, the latter class will be glad to know they can skip building and loading two plugins 🙂
Bribes and gifts accepted if you were waiting for these binary codecs 😛 (no, just kidding).
FFmpeg-compatible demux_real will come, eventually.. the problem is that the data needed by the Real audio decoder and the data needed by FFmpeg aren’t the same, so I have to hack around to provide data for both.. and the problem of this is that I would end up having to copy the same buffer twice, which is far from being fast.. the alternative is to make FFmpeg’s decode aware of the buffer type… oh well, I’ll see what I can do about that in the next days.