Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: The version of dvdauthor shipped with F13 does not create text subtitles Version-Release number of selected component (if applicable): How reproducible: spumux -m dvd spu.xml <menudvd.mpg> menu.mpg produces output INFO: Locale=en_US.utf8 INFO: Converting filenames to UTF-8 INFO: Picture /storage/burn/image.png had 2 colors INFO: Picture /storage/burn/highlight.png had 2 colors INFO: Picture /storage/burn/select.png had 2 colors INFO: Autodetect 0 = 0x0-720x576 INFO: Pickbuttongroups, success with 1 groups, useimg=1 INFO: Found EOF in .sub file. INFO: Max_sub_size=4556 WARN: Button y coordinates are odd for button Smallville 806 813: -1x-1--1x-1; they may not display properly. WARN: Button y coordinates are odd for button Smallville 814 819: -1x-1--1x-1; they may not display properly. WARN: Button y coordinates are odd for button Smallville 820 822: -1x-1--1x-1; they may not display properly. dvdauthor compiled against libpng only produces the correct output as below DVDAuthor::spumux, version 0.6.18. Build options: gnugetopt iconv fribidi Send bugs to <dvdauthor-users.net> INFO: Locale=en_US.utf8 INFO: Converting filenames to UTF-8 INFO: PNG had 3 colors INFO: PNG had 3 colors INFO: PNG had 3 colors INFO: Autodetect 0 = 70x140-323x352 INFO: Autodetect 1 = 390x140-643x352 INFO: Autodetect 2 = 70x360-323x572 INFO: Autodetect 3 = 390x360-643x572 INFO: Pickbuttongroups, success with 1 groups, useimg=1 INFO: Found EOF in .sub file. INFO: Max_sub_size=7772 INFO: 1 subtitles added, 0 subtitles skipped, stream: 32, offset: 0.50 Statistics: - Processed 0 subtitles. - The longest display line had -1 characters. - The maximum number of displayed lines was 0. - The normal display height of the font arial.ttf was 0. - The bottom display height of the font arial.ttf was 0. - The biggest subtitle box had 7772 bytes. Problem appears to be Graphicsmagics but certainly shows up in spumux
I have the same issue, and also a proposal for a patch in dvdauthor sources. Something definitely changed when GraphicsMagick transitioned from version 1.3.7 (fc12) to version 1.3.12 (fc13), however there is a piece of code in file src/subgen-image.c of package dvdauthor that reads as follows (from line 206): #if defined(HAVE_MAGICK) && MagickLibVersion >= 0x600 p.t=pdata[x*4+3]; #else p.t=255-pdata[x*4+3]; #endif this piece of code is compiled only if dvdauthor is linked against ImageMagick (HAVE_MAGICK is defined in that case) or against GraphicsMagick (HAVE_GMAGICK is defined). It seems that the first of the two mutually optional lines is used instead of the other. Here is my proposal: --- src/subgen-image.c.orig 2010-06-03 18:35:33.421183962 +0200 +++ src/subgen-image.c 2010-06-03 18:44:29.665436079 +0200 @@ -203,7 +203,7 @@ p.b=pdata[x*4+2]; // the meaning of RGBA swapped with ImageMagick 6.0.0... // ...but not with GraphicsMagick -#if defined(HAVE_MAGICK) && MagickLibVersion >= 0x600 +#if (defined(HAVE_MAGICK) && MagickLibVersion >= 0x600) || (defined(HAVE_GMAGICK) && MagickLibVersion >= 0x90000) p.t=pdata[x*4+3]; #else p.t=255-pdata[x*4+3]; the symbol MagickLibVersion has a somewhat strange value defined in /usr/include/GraphicsMagic/magick/version.h, which seems to have nothing to do with the textual version; it was 0x050200 in version 1.3.7 of GraphicsMagick (fc12) and is now 0x090600 in version 1.3.12, so the comparison value 0x90000 is just an arbitrary proposal.
Thanks for investigating, Maurizio. Could you or "redtux" provide a set of files (spu.xml, *.png and *.mpg, link in private mail if you prefer especially if the mpg is large) that can be used to reproduce this? I'd like to verify this myself and to dig deeper to find in which GraphicsMagick version things changed.
(In reply to comment #2) > Thanks for investigating, Maurizio. Could you or "redtux" provide a set of > files (spu.xml, *.png and *.mpg, link in private mail if you prefer especially > if the mpg is large) that can be used to reproduce this? I'd like to verify > this myself and to dig deeper to find in which GraphicsMagick version things > changed. You can find sample files in http://dmf.unicatt.it/~paolini/spumux/ menu.xml buttons*.png menu.mpg are input files for "spumux menu.xml <menu.mpg >menu_with_subtitles.mpg there are also two resulting mpg: menu_nofix.mpg obtained with the last dvdauthor rpm (dvdauthor-0.6.18-1.fc13.i686.rpm), whereas menu_fix.mpg was obtained with my proposed fix. You should note that spumux wrongly finds only 1 color in the png images: [...] INFO: Picture buttons.png had 1 colors [...] whereas it shoud find 2 colors.
Thanks, revised patch submitted upstream: https://sourceforge.net/mailarchive/forum.php?thread_name=1275825478-17482-1-git-send-email-ville.skytta%40iki.fi&forum_name=dvdauthor-developer Lawrence, can we expect a new upstream dvdauthor release soon?
(In reply to comment #4) > Thanks, revised patch submitted upstream: > > https://sourceforge.net/mailarchive/forum.php?thread_name=1275825478-17482-1-git-send-email-ville.skytta%40iki.fi&forum_name=dvdauthor-developer > > Lawrence, can we expect a new upstream dvdauthor release soon? Thank you! I had a look and realized that my patch would be problematic because it would require some dependency between dvdauthor and graphicsmagick rpm packages. If the next upstream dvdauthor release is not due shortly it could make sense to include your patch as part of an updated rpm...
(In reply to comment #5) > Thank you! I had a look and realized that my patch would be problematic because > it would require some dependency between dvdauthor and graphicsmagick rpm > packages. Sure, but it's not your fault, the problem already existed for ImageMagick in upstream code... > If the next upstream dvdauthor release is not due shortly it could > make sense to include your patch as part of an updated rpm... That's the plan; if no new upstream release is imminent, I'll take a look at shipping a patched package next week.
I’ve been doing a lot of major changes to DVDAuthor, and there’s still some more I’d like to do before calling it another release. So yes, probably best if you do this patch for Fedora for now. I made a slight change (moved the test outside of the loops), and committed my version of the patch here: http://github.com/ldo/dvdauthor/commit/b48152519fd189b19a85b89d7d9330164c840e24 I would also like to invite anybody who’s serious about using DVDAuthor to please try out the Git version here http://github.com/ldo/dvdauthor and let me know of any bugs. Lawrence D’Oliveiro principal developer, DVDAuthor
dvdauthor-0.6.18-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/dvdauthor-0.6.18-2.fc13
dvdauthor-0.6.18-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update dvdauthor'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/dvdauthor-0.6.18-2.fc13
dvdauthor-0.6.18-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.