Bug 245155 - No bmp support in spumux
No bmp support in spumux
Product: Fedora
Classification: Fedora
Component: dvdauthor (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-06-21 08:27 EDT by Otto J. Makela
Modified: 2008-02-13 18:17 EST (History)
0 users

See Also:
Fixed In Version: 0.6.14-5.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-13 18:17:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
son2xml perl version (1.45 KB, text/plain)
2007-06-24 08:58 EDT, Otto J. Makela
no flags Details

  None (edit)
Description Otto J. Makela 2007-06-21 08:27:23 EDT
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):

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.
Comment 1 Ville Skyttä 2007-06-21 10:49:26 EDT
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.
Comment 2 Otto J. Makela 2007-06-24 08:58:14 EDT
Created attachment 157709 [details]
son2xml perl version
Comment 3 Otto J. Makela 2007-06-24 08:58:35 EDT
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.
Comment 4 Ville Skyttä 2007-06-24 09:17:28 EDT
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]'

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?
Comment 5 Otto J. Makela 2007-06-24 09:36:58 EDT
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.
Comment 6 Ville Skyttä 2008-02-13 18:17:00 EST
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- will be shipped for them as updates.

Note You need to log in before you can comment on or make changes to this bug.