Bug 803578 - Spumux fails with "Encoded row takes more than 1440 bits"
Summary: Spumux fails with "Encoded row takes more than 1440 bits"
Keywords:
Status: CLOSED DUPLICATE of bug 788246
Alias: None
Product: Fedora
Classification: Fedora
Component: dvdauthor
Version: 16
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ville Skyttä
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-15 06:25 UTC by Otto J. Makela
Modified: 2012-03-17 19:57 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-17 19:57:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Otto J. Makela 2012-03-15 06:25:33 UTC
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 <dvdauthor-users.net>

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 14:22:06 UTC
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 15:53:41 UTC
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 19:42:48 UTC
That was it, downgrading to GraphicsMagick-1.3.12-6.fc16.x86_64 makes spumux work again.

Comment 4 Ville Skyttä 2012-03-17 19:57:55 UTC

*** This bug has been marked as a duplicate of bug 788246 ***


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