[ATrpms-users] Mytharchive picture corruption in fc10
Axel Thimm
Axel.Thimm at ATrpms.net
Sat Jan 24 10:13:15 CET 2009
On Mon, Jan 19, 2009 at 03:00:12PM +0000, John Pilkington wrote:
> Axel Thimm wrote:
> > On Mon, Jan 12, 2009 at 04:13:06PM +0000, John Pilkington wrote:
> >> I have a large stack of MythTV DVDs created under CentOS5 that play
> >> well. i have a few created under fc10 that do the same, but when their
> >> creation requires the use of tcrequant (ie, when the input files are
> >> slightly too large for the disk) the fc10 picture is often corrupt, with
> >> small transient rectangles superimposed on the normal picture.
> >> Strangely, although tcrequant is applied equally to all the recordings
> >> on a disk, the visibility of the corruption on them may vary.
> >>
> >> This should perhaps have gone to mythusers, or the mythtv trac system,
> >> but tcrequant is part of the transcode package (unless it's distinct
> >> copy built into mythtv?) and I thought an airing here might be useful.
> >> Known memory leaks?
> >
> >
> > In principle builds for CentOS5 and Fedora 10 are the same speaking
> > from the POV of the source. Theuy are just being built in different
> > environments (different vendor libraries and compilers).
> >
> > Perhaps a bug in alignment in some struct that triggers differently
> > depending on the compiler used? I would indeed try to cross-check this
> > on mythtv-users. Maybe other distros see this, too, and the diagnosis
> > can be extended.
>
> No takers yet from my post on mythtv-users, but
>
> Sun Jan 18 11:40:35 CET 2009
> transcode 1.1.0 Final Release
> Highlights of the changes since 1.1.0 RC 5:
> # tcrequant is now deprecated and not built by default.
>
> http://tcforge.berlios.de/archives/2009/01/18/transcode_1_1_0_final_release/index.html
>
> :-(
Is there a recommendation by transcode developers of what to use
instead of tcrequant?
I checked the archives a bit and it looks like tcrequant does have a
bad bug track which could explain the random corruption you experience
(random in the sense that building it in one environment produces a
functional build and in another a bad one).
http://www.mail-archive.com/transcode-devel@exit1.org/msg00778.html
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-users/attachments/20090124/53fc859e/attachment.bin
More information about the atrpms-users
mailing list