[FFmpeg-devel] [PATCH] DNxHD/VC-3 encoder

Michael Niedermayer michaelni
Sun Sep 16 21:38:53 CEST 2007


Hi

On Fri, Sep 07, 2007 at 08:05:28PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Sep 07, 2007 at 09:17:49AM -0600, Loren Merritt wrote:
> > On Fri, 7 Sep 2007, Michael Niedermayer wrote:
> > 
> > > when people start using qsort you know theres something wrong in their
> > > encoder (or at least not optimal)
> > >
> > > so, lets first check if i understand the constraints
> > > * its possible to change qscale per macroblock and it doesnt cost anything
> > > * theres a fixed number of bits available for each frame (pre mpeg1 design)
> > >
> > > in that case the optimal solution (though not fastest) is to do a
> > > binary search over lambda (using the number of bits and the ones available
> > > to find the best lambda which results in a frame which is not too large)
> > >
> > > then for each such lambda, find the best qscale for each MB, again by
> > > binary search minimizing SSD + bits*lambda (that way we know the best
> > > qscales and how many bits the frame would need)
> > 
> > Your algorithm produces the same decisions as the one with qsort. I don't 
> > know which is faster.
> > 
> > Consider the list of possible block encodings sorted by 
> > delta_ssd/delta_bits. Optimizing for qps at any given lambda will produce 
> > some prefix of that list. i.e. for any lambda, there is some 
> > position in the list such that all preceding entries have ssd/bits 
> > better than lambda, and all following entries have ssd/bits worse 
> > than lambda. So instead of evaluating bits(lambda) as a black box and 
> > searching for a specified values of bits, construct the function 
> > lambda(bits) and evaluate it at the specified value of bits.
> 
> yes, but as far as i can see thats not what the current code does, it just
> tries qscale and qscale+1 if it would try all qscale then yes they would
> be identical

just to clarify my original review ...
i dont mind if the code uses qsort, what i was complaining about was that
it isnt finding the optimal (in the RD sense) solution

if its changed to find the optimal one or its demonstrated that the
PSNR/bitrate difference is negligible then iam happy with that part

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070916/1dc42622/attachment.pgp>



More information about the ffmpeg-devel mailing list