Red Hat Bugzilla – Bug 245155
No bmp support in spumux
Last modified: 2008-02-13 18:17:00 EST
Description of problem: Although the manual page for spumux (included in the dvdauthor package) states that it should support bitmap subtitle files in both png or bmp format, current release seems to have been compiled to support png only. This is a bit of a problem, since ProjectX (one of the few linux video cutting tools with working subtitle support) only produces bmp bitmaps from dvb recordings. Version-Release number of selected component (if applicable): 0.6.14-1.fc7 How reproducible: Giving spumux a xml file containing references to bmp files gives the errors: ERR: File videofile_st00000p1.bmp isn't a png WARN: Bad image, skipping line -1 Additional info: Earlier releases (at least in fc5) did have bmp support included in spumux.
BMP support would IIRC require compiling with ImageMagick, but ImageMagick pulls in an untolerable amount of dependencies through librsvg2, that's why it's not done by default in dvdauthor. See bug 212478. Until the ImageMagick/librsvg2 dependency bloat problem has been fixed, dvdauthor can be locally rebuilt with ImageMagick support with "rpmbuild --rebuild --with imagemagick dvdauthor*src.rpm" By the way, I would guess that it'd be pretty much trivial to make ProjectX output PNG's instead of BMP's - built-in PNG support is included in all semi-modern JRE's I'm aware of, and I think PNG is more of a standard than BMP which (if correct) would make it a better choice.
Created attachment 157709 [details] son2xml perl version
I can see why you'd want to skip this huge dependency chain, but unfortunately the local rebuild solution you give does not seem to alter spumux behavior in this respect. Maybe also some other flags are required? ProjectX seems to currently be a more or less dead project -- the software is available and works fine, but I wouldn't hold my breath expecting any further development soon. As an interim measure, I've changed son2xml (a helper script used convert the subtitle description file format) to do the conversion externally using optipng.
Hm, curious, could you post the output of "rpm -qRp /path/to/dvdauthor*rpm" for the binary packages you rebuilt using "--with imagemagick"? If it was successfully built with it, things like libMagick.so.* and libWand.so.* should be listed. I just did a test build on F7 x86_64 using --with imagemagick, and: $ rpm -qRp dvdauthor-0.6.14-1.cmn7.x86_64.rpm | grep 'lib[WM]' libMagick.so.10()(64bit) libWand.so.10()(64bit) Quickly peeking at the source, this seems to imply that HAVE_MAGICK was defined during configure, and the code that emits the error in your initial comment shouldn't have even been compiled in... maybe a dumb question, but you did remember to actually install the binary packages rebuilt --with imagemagick, right?
You of course are correct, I suspect I had both the i386 and the x86_64 version (with different compile options) installed at the same time which caused no end of confusion on my part.
0.6.14-5 is currently being built with GraphicsMagick support. GraphicsMagick has considerably fewer dependencies than ImageMagick in the first place, and after today's fixes in Rawhide, even fewer; quite acceptable anyway. I do not intend to ship this for < F9 unless today's changes in libwmf-0.2.8.4-18 will be shipped for them as updates.