[FFmpeg-devel] [PATCH] DNxHD 10-bit support v5
joseph at mirriad.com
Mon Jun 13 11:56:38 CEST 2011
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
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
BTW, the reasons we do our own colour conversion instead of relying on
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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the ffmpeg-devel