[mythtv-users] Mytharchive picture corruption in fc10.x86_64 build

John Pilkington J.Pilk at tesco.net
Thu Jan 15 22:17:48 UTC 2009


I posted about this earlier this week to the ATrpms users list:  here's 
the original, followed by Axel's response and a few more details.

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 dvd) 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.
> -- Axel.Thimm at ATrpms.net 

I burn my dvds from .iso images created by Mytharchive.  The corrupt 
images are from an fc10.x86_64 system.  The older i686 box has been fc3, 
fc5, Centos5.2 and has never had this problem.  All have used the ATrpms 
builds of MythTV.

Almost all the recordings are from UK dvb-t, pre-processed to leave one 
stereo mp2 channel without subtitles, which are then Mythtranscoded 
using a cutlist before entering Mytharchive.  Mytharchive demultiplexes, 
converts sound to ac3, applies tcrequant if needed to fit into the 
available space, remultiplexes and creates the .iso image.  I very 
rarely re-encode video, and never within Mytharchive.

Mytharchive failures have been very rare, and with tcrequant (video 
shrinkage) factors almost always less that 5 percent the video quality 
has not shown noticeable degradation. tcrequant in working order is a 
useful tool and I would like to be able to rely on its availability in 
the new system.

Has anyone else seen this behaviour?  Does anyone have any idea of what 
might be going wrong?

Thanks in advance,

John Pilkington









More information about the mythtv-users mailing list