[Ffmpeg-devel] Re: ffmpeg-devel Digest, Vol 19, Issue 220

[Karl H. Beckers]

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 ...
> 

OKOKOK,
I'll have a look at encode_block() and see if I can even remotely
understand what needs to be done for mjpeg.

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, let alone trellis,
hardly pts, dts, etc. etc .... plus I can't afford to try to build up
that knowledge at least before xvidcap 1.1.4 is released.
After that I might try (even if I did not intend to build up that
knowlege) because I have some other things I would like to get from the
API ... being the dumb user I am ;) (but I'll open a new thread for
that).


> > 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?

Cheers,

Karl.