Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Spumux fails with "Encoded row takes more than 1440 bits"|
|Product:||[Fedora] Fedora||Reporter:||Otto J. Makela <om>|
|Component:||dvdauthor||Assignee:||Ville Skyttä <ville.skytta>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||cn6uw7d02, from-redhat, ville.skytta|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-03-17 15:57:55 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Otto J. Makela 2012-03-15 02:25:33 EDT
Description of problem: Subtitle muxing with spumux (from dvdauthor package) has started to fail with the error message "Encoded row takes more than 1440 bits", probably due to some underlying library change. This same work flow used to work in January 2012, but I have been unable to determine which library change since has caused it to fail. Version-Release number of selected component (if applicable): 0.7.0 How reproducible: Every time Steps to Reproduce: 1. Start with m2v, mp2 and subtitle xml+png files 2. mplex -V -f 8 -o /dev/stdout file.m2v file.mp2 | spumux -m dvd file.d/spumux.xml > dvd.mpg Actual results: DVDAuthor::spumux, version 0.7.0. Build options: gnugetopt graphicsmagick iconv freetype fribidi fontconfig Send bug reports to <firstname.lastname@example.org> INFO: default video format is NTSC INFO: Picture file.d/00+00+24.97.png had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel INFO: Picture file.d/00+00+30.74.png had 3 colors INFO: Constructing blank hlt INFO: Constructing blank sel ERR: Encoded row takes more than 1440 bits. Please simplify subtitle. Expected results: Appropriately subtitle-enhanced mpeg stream produced Additional info: Everything still works with old Fedora 15 installation.
Comment 1 japa-fi 2012-03-15 10:22:06 EDT
The issue is not with the png file that is to be handled_ The first file will always be processed OK, the second one fails. Having all processed files identical (copy the 1st file which had no problem over the remaining ones) will still produce the error on the second file that is being processed.
Comment 2 Ville Skyttä 2012-03-15 11:53:41 EDT
I haven't had a chance to look into this myself yet, but Cc'ing upstream. One suspect could be GraphicsMagick which has been updated to a version which has some PNG regressions, see bug 788246.
Comment 3 Otto J. Makela 2012-03-15 15:42:48 EDT
That was it, downgrading to GraphicsMagick-1.3.12-6.fc16.x86_64 makes spumux work again.