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

[Baptiste Coudurier]

Hi Michael,

Michael Niedermayer wrote:
> 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
> 

I tried lagrange. I keep the qsort rc because it is useable (> real time
on quad core cpu with variance, -5 fps for ssd), rdo one is encoding at
4 fps :/

Im wondering if I did screwed up the implementation because I have an
IMHO negligeable gain with rdo.

I reused existing quant functions.

Threaded functions must return int else you get a warning.

About encode_dc, it will be complicated to reuse existing ones because:
mpeg12 use some static tables and generation code.
mjpeg use uint16_t for dc_codes.

About mb_var_thread, existing function use current_picture and set
variables I don't need, mb_mean, and use me field too ...

Attached are some psnr results with one HD uncompressed sample I have.

Any other optimization because what Loren suggested earlier ?

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: psnr.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070924/7a72aa89/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dnxhd_encoder5.patch
Type: text/x-diff
Size: 34764 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070924/7a72aa89/attachment.patch>