[ATrpms-users] Mytharchive picture corruption in fc10

[John Pilkington]

Axel Thimm wrote:
> 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
> 
I have posted on both myth-dev and transcode-users asking about 
alternatives: so far one reply pointing to

http://vamps.sourceforge.net/

which is apparently another wrapper for the same engine - and there's a 
Windows package too, ReJig. They may have relevant modifications, I 
don't know.

I learned the word 'grok' and get the impression that no-one groks this 
code, which seems to use lots of unexplained integer arrays and 
generally lacks explanations of what it's doing.

Of course mencoder can shrink video too, but the requant magic is much 
much quicker.

It worries me that the environment does affect the result; something, 
somewhere must be overflowing but it's not clear where.

I see your fc10.x86_64 transcode package has dropped tcrequant - haven't 
looked yet at el5.i686

John P