[FFmpeg-devel] [PATCH] RoQ video encoder

Michael Niedermayer michaelni
Sat Jun 2 13:18:34 CEST 2007


Hi

On Fri, Jun 01, 2007 at 09:30:02PM -0400, Eric Lasota wrote:
> Michael Niedermayer wrote:
> > it may or may not end up the same as your sorting code, i dont know ...
> I just did some verification, and the rate distortion on all 
> non-selected possibilities is always worse than the last entry to be 
> accepted.
> > but a single pass over the possibilities, with no sorting, no lists, ...
> > beats your code by a quite large amount in terms of simplicity
> I removed the sorting from the plist builder, including the two sort 
> functions, it now consumes 130 fewer lines of code.  I sent Vitor the 
> replacement.  The number of lines specific to this method, including the 
> existing code, is around 75.

its hard to comment on code i dont see ...
why not post the relevant part of the file?


> 
> Keeping the progressive reducer in is a good idea as the quality factor 
> needed to maintain a bitrate gets extremely erratic, and it may be 
> neccessary to cap frame sizes, although I am admittedly a newbie when it 
> comes to rate control.

if you want to find the smallest lambda which results in a frame below a
specific size then something like the following could be used

for i in all macroblocks in the image{
    for p in all possibilities of the current MB{
        bits      [i][p]= find_bit_count();
        distortion[i][p]= find_distortion();
    }
}

int lambda=-1;
for(delta=65536; delta; delta>>=1){
    int lambda2= lambda+delta;
    int bits= 0;
    for i in all macroblocks in the image{
        int mb_rd= INT_MAX;
        int mb_bits;
        for p in all possibilities of the current MB{
            if(distortion[i][p] + lambda2*bits[i][p] < mb_rd){
                mb_bits= bits[i][p];
                mb_rd= distortion[i][p] + lambda2*mb_bits;
            }
        }
        bits+= mb_bits;
    }
    if(bits > max_bits)
        lambda= lambda2;
}


also the lambda factor could be used when deciding the codebook size

and last, id like to repeat that pure CBR is a very bad idea
you could look at lambda as a value which says how much distortion
you would be willing to trade for 1 bit, so very wildly variing it between
frames to maintain a constant size per frame is like saying one bit of this
frame is worth X distortion while 1 bit in the next frame is worth 100*X
distrortion ...

also id say libavcodec/ratecontrol.c could be used if you want ratecontrol
but this can easily be added later, that is after the encoder is in svn ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- 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/20070602/e1d4176d/attachment.pgp>



More information about the ffmpeg-devel mailing list