[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