[FFmpeg-devel] [PATCH] RoQ video encoder (take 4)

Michael Niedermayer michaelni
Thu Jun 14 22:30:07 CEST 2007


On Thu, Jun 14, 2007 at 07:44:55AM -0400, Eric Lasota wrote:
> Michael Niedermayer wrote:
> > IIRC theres a used count and if its 0 we drop a codebook
> > so if we just consider codebooks with a small used value (like 1)
> > for droping then there shouldnt be much reindexing needed
> >   
> I still would imagine that would be difficult, a good codebook generator 
> produces very even distribution.

a good codebook generator produces an optimal codebook the problem isnt
the generator but rather that not all blocks will use the 4x4 and 2x2
codebooks, they will rather just use one or the other or they will use
motion compensation from the previous frame
-> the points the codebook generator saw are no longer correct and as
such the codebook is no longer optimal and should be regenerated and
or less usefull codebooks droped

as example think about a block which can be represented by a codebook entry
with ratedistortion 1000 or alternatively with motion compensation with
ratedistortion 1001, if the codebook isnt used anywhere else it should be 
droped the same is true if 2 codebooks equally well approximate a block and
one is not used by any other blocks ...


> > codebook size estimation probably would have to be done after decidng
> > the macroblock types ...
> > which might lead to a iterative loop of codebook generation and macroblock
> > type decission)
> >   
> Deciding the macroblock types requires being indexed.  It's a 
> chicken-and-egg problem I decided to sidestep completely.  Thresholding 
> never quite worked when I tried it, though that's probably the best option.

its not hard to show that thresholding cannot work in many cases

take a completely black (y=0 u=v=128) frame next frame is y=1 u=v=128)
this can trivially be encoded with no quality loss with a single codebook
but if you use a threashold it will use 0,0 motion vectors and be worse

> > not fast but i suspect these cases are rare
> >   
> Depends on the target bitrate.  Sharp scene changes can also cause 
> potentially cause drastic increases in size when targetting quality.

this problem will become signficantly less serious when ratecontrol
is added ...

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/caa6a82d/attachment.pgp>

More information about the ffmpeg-devel mailing list