[x265] Encoder::configure() frame padding

[Deepthi Nandakumar]

Hello Matt,

On Fri, Dec 6, 2013 at 7:54 PM, Matt Johnson <johnso87 at illinois.edu> wrote:

> Hi all,
>         The following code is in Encoder::configure():
>
> //======== set pad size if width is not multiple of the minimum CU size
>     uint32_t maxCUDepth = (uint32_t)g_convertToBit[_param->maxCUSize];
>     uint32_t minCUDepth = (_param->maxCUSize >> (maxCUDepth - 1));
>     if ((_param->sourceWidth % minCUDepth) != 0)
>     {
>         //pad width to multiple of minCUDepth
>     }
>     ...
>     if ((_param->sourceHeight % minCUDepth) != 0)
>     {
>         //pad height to multiple of minCUDepth
>     }
>
> I had a couple of questions:
> * Should minCUDepth be renamed minCUSize?
>
Yes, you have a point. It's size, not depth.


> * Aren't the first two lines a convoluted way of always computing "8"? x
> >> ((log2(x) - 2) - 1) = x / 2^(log2(x) - 3) = 8
>

Yes, the minCUSize will always be 8, no matter what the maxCUSize is. Calls
for a macro MIN_CU_SIZE.


> * Is there any reason for maxCUDepth or minCUSize to be set via command
> line or some other way instead of being implicitly computed here?
>

The maxCUSize needs to be accessible via commandline, because it can have
values 64/32/16 - thus varying maxCUDepth. Lowering the CUsize improves
performance (the larger and more expensive CU sizes do not need to be
analyzed, increases no. of CTURows for wpp etc). Predictably, it also
lowers compression efficiency. Our fastest presets set the maximum CU size
to 32 (instead of 64). minCUSize - yes, like you said earlier, it's always
8.


>
> Thanks,
> Matt
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20131207/46b88daf/attachment.html>