[FFmpeg-devel] [PATCH] DNxHD 10-bit support v5

[Joseph Artsimovich]

On 11/06/2011 01:05, Michael Niedermayer wrote:
>> it might make sense to do the abs first then check against a threshold
>> so the multiply&  shift is only done when the value isnt going to be
>> 0 anyway. 0 is the most common value
>> so this may be faster
> also switching to 10 bit PIXFMT as baptiste suggested could be done
>
> But none of these things should cause the patch to be delayed for
> months. the regression test failure must be fixed though
> That is, if you prefer to work on the rest later iam in favor of
> applying (as i planed) once the regression is fixed / explained
The attached patch fixes the regression.  To be applied on top of the 
other patches.

As for the 10 bit vs 16 bit formats, let me give you my perspective.
If I got that correctly, the comment in the header suggests storing 
[0..1023] samples in YUV422P16.  I am not a fan of that idea.  Is there 
currently even a way to tell libswscale how many bits are really being 
used?  Also keep in mind that some applications (ours included) want to 
do their own colour conversion, and introducing this idea of "storage 
bits != logical bits" might require architectural changes.
Another option is to use 10-bit planar formats.  That sounds good in 
theory, but in practice it pushes the complexity out of ffmpeg, to 
libraries like libquicktime that uses ffmpeg internally, and also to 
applications that want to do their own colour conversion.
The third option, which my patches use, is to scale 10 bit samples to 
the full 16bit range.  This approach is my favorite and is the least 
painful overall.

BTW, the reasons we do our own colour conversion instead of relying on 
libswscale, are:
1. libswscale allows you to choose between ITU-601 and ITU-709 for YUV 
-> RGB conversion but not the other way.
2. The "full range dnxhd" turned out to be more than full range.  I call 
it "overstretched range".  That is, U and V values of 0 and 255 don't 
correspond to -0.5 and 0.5, instead they correspond to something like 
-0.488 and 0.488.  These are approximate values we got from our least 
squares estimation.  Eventually we've got more precise ones, by 
adjusting them manually till we saw no difference on a broadcast 
monitor.  Libswscale doesn't support that model at all.

-- 
Joseph Artsimovich
Software Developer
MirriAd Ltd

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: respect_user_specified_idct_algo.patch
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110613/003251be/attachment.ksh>