[Ffmpeg-devel] Re: ffmpeg-devel Digest, Vol 19, Issue 220
Fri Oct 27 21:06:50 CEST 2006
On Fri, Oct 27, 2006 at 08:35:14PM +0200, Karl H. Beckers wrote:
> Am Donnerstag, den 26.10.2006, 20:14 +0200 schrieb
> ffmpeg-devel-request at mplayerhq.hu:
> > [...]
> > > Michael,
> > > I only sent the diff to highlight the issue not to suggest that this
> > > should be the fix or applied as a patch. I'm also all with you about
> > > adding the feature (though that won't be me ;S),
> > why not? its not that hard, first just fill the length array with the
> > correct vlc lengths see mjpeg.c:encode_block() then ensure that the
> > assumed dequantization and assumed number of bits in trellis_quant
> > is correct ...
> I'll have a look at encode_block() and see if I can even remotely
> understand what needs to be done for mjpeg.
encode_block() just takes some coefficients (16bit integers) and stores
them using a more compact rle (number of zero coeffs + value of the first non
zero coeff) vlc/huffman codes, this is much simpler then it sounds
> The answer to "why not" is easy: because I'm just a dumb user of the API
> and can make no claim to understand even 10% of what's going on behind
> the scenes. I don't even know what a quantiser is,
dequantization is nothing else then scaling a value up
that can be
input * X (all are integers)
input * X + some small value depening on X and inputs sign
quantization is just the inverse aka finding the input which when
dequantized is closest to the correct value (this is ....big surprise
nothing else then just a division with the correct rounding)
also in practice there is some bias added to favor smaller values
as they need fewer bits to be stored
trellis_quant now finds the optimal quantization optimal here means
minimization of number of bits + constant*(sum of squared errors)
> > > but then, if the encoders
> > > are not required to put a value there (or perhaps they are and mjpeg
> > just
> > > doesn't comply) the code shouldn't rely on it being filled.
> > >
> > > Anyway, perhaps the attached bit is more agreeable as a quickfix.
> > no, dct_quantize_trellis_c() should never be called if the length
> > arrays
> > arent initalized
> So, in RFC-speak ... an encoder SHOULD NOT call it or MUST NOT call it?
> In other words, will fixing mjpeg be enough or should we go and find the
> places where the function is called and place checks there?
MUST NOT of course, there should be a check in MPV_encode_init() which
checks that that trellis is only used with codecs supporting it, which
codecs that are ... well i dont know h263/mpeg4/mpeg1/mpeg2 maybe +
variants of them like flv, someone simply would need to check through
the list of codecs from ffmpeg -formats ...
but ... if you add support for just one more codec to trellis that is
much more important and usefull then checking the parameters validity
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is
More information about the ffmpeg-devel