[FFmpeg-devel] [PATCH] RoQ video encoder (take 4)
Michael Niedermayer
michaelni
Thu Jun 14 22:16:12 CEST 2007
Hi
On Thu, Jun 14, 2007 at 06:39:07PM +0200, Vitor wrote:
> Hi
>
> Eric Lasota wrote:
> > Michael Niedermayer wrote:
> >
> >> this if() does seem unneeded
> >> btw, what is the purpose of the numCB4 == 256 special case above this if()?
> >>
> >>
> >
> > The two codebook counts are stored as a 16-bit value, but the way Quake
> > 3 interprets it is as follows:
> >
> > if (!roq_flags) {
> > two = four = 256;
> > } else {
> > two = roq_flags>>8;
> > if (!two) two = 256;
> > four = roq_flags&0xff;
> > }
> >
> > The problem with this is that if the result has, for example, 254 2x2
> > entries and 256 4x4 entries, Quake 3 will interpret that as 254 2x2
> > entries and ZERO 4x4 entries. Third-party decoders typically check the
> > chunk size to see if there are 4x4 entries or not, Quake 3 doesn't.
> > Consequently, the only correct way to store 256 4x4 entries is with 256
> > 2x2 entries.
> >
> >
>
> Wouldn't it be better to just encode a maximum of 255 4x4 cb entries? It
> won't broke nor quake 3 nor third party decoders and is pretty
> straightforward to code (and anyway anyone encoding with a decent
> quality won't need so many 4x4 codebooks)...
agree, 255 max makes sense
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070614/5c6b8d90/attachment.pgp>
More information about the ffmpeg-devel
mailing list