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

[Baptiste Coudurier]

Baptiste Coudurier wrote:
> 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 ?

Ping ? No objections ? I guess I can commit then.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312