Francesco Romani wrote:
On Thu, 2009-01-22 at 23:05 +0000, John Pilkington wrote:
Hi,
[...]
So it seems to me that tcrequant is *not* broken on all platforms and I
would not like it to disappear globally unless, of course, there is a
reliable and effective alternative.
I do agree that the tcrequant issue is annoying.
But IMHO to not exactly know where and why a given software is broken
it's a Major brokeness.
tcrequant will not disappear soon: it's deprecated by default, but
reenabling it it's just a matter of doing
configure --enable-deprecated
I've some clues about the actual root of the problem, but nailing down
the real problem(s) isn't easy. I'm filing a bug in order to track this
issue, but following my gut feeling, this will not be easy nor quick.
Bests,
Thanks for your reply. As I said in an earlier post, the original code
from Metakine has been replaced on their website by a re-write, and that
has been ported to linux, and extended, in vamps. I have tried
vamps -E 1.4 -a 1 -p -i inj_txt < input.VOB > shrunk.VOB
and it seems to work well. Here inj_txt is the arbitrary name of a
small text file that will be created and should not exist on entry. It
seems to be used in vamps to adjust the shrinkage factor dynamically
after each buffer is processed. Here the factor, 1.4, relates the
overall file sizes. A -e option relates just the sizes of the video
components. Factors up to 10.0 are nominally supported - or 5.0 in the
current Metakine download.
vamps is supposed to work with more than one non-video channel too, but
I haven't tried that.
I suppose it would be possible to replace the old section of code in
tcrequant by the new, although the new version needs to know the
input-stream-length if it's not given a regular file. For my purposes,
the VOB-to-VOB package is probably better long-term, if it continues
to work, since it ought to be pipelineable before dvdauthor: but it
isn't a simple plug-in replacement for tcrequant.
John Pilkington
