Bug 803578

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>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	16	CC:	cn6uw7d02, from-redhat, ville.skytta
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-17 19:57:55 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 ***