[x265] API or documentation problem for tiny images

[Kavitha Sampath]

Hi Vittorio,
Apologies for the late response and thank you for pointing out the
discrepancy in our documentation and error message.
To my knowledge, if the picture width/height is not a multiple of minimum
CU size then the picture is padded. Images smaller than 64x64 should be
padded and encoded without the need of modifying the maxCUSize manually. We
acknowledge the problem you have reported and will get back to you with a
good solution very soon.


Regards,
Kavitha

On Mon, May 7, 2018 at 9:06 PM, Vittorio Giovara <vittorio.giovara at gmail.com
> wrote:

>
>
> On Tue, May 1, 2018 at 2:20 PM, Vittorio Giovara <
> vittorio.giovara at gmail.com> wrote:
>
>>
>>
>> On Fri, Apr 27, 2018 at 2:38 PM, Vittorio Giovara <
>> vittorio.giovara at gmail.com> wrote:
>>
>>> Hi, when encoding very small videos, less than 64x64 x265 throws an
>>> error.
>>>
>>> x265 [error]: Picture size must be at least one CTU
>>>
>>> however the documentation clearly states that any valid size is supported
>>>
>>>     /* Width (in pixels) of the source pictures. If this width is not an
>>> even
>>>      * multiple of 4, the encoder will pad the pictures internally to
>>> meet this
>>>      * minimum requirement. All valid HEVC widths are supported */
>>>     int       sourceWidth;
>>>
>>>     /* Height (in pixels) of the source pictures. If this height is not
>>> an even
>>>      * multiple of 4, the encoder will pad the pictures internally to
>>> meet this
>>>      * minimum requirement. All valid HEVC heights are supported */
>>>     int       sourceHeight;
>>>
>>> This does not seem the case, as you need to fiddle with the maxCUSize
>>> manually, and still doesn't work for images that are smaller than 16x16
>>>
>>> x265 [error]: max cu size must be 16, 32, or 64
>>>
>>> It doesn't seem like x265 exposes the crop parameters either (only the
>>> default display window which is not appropriate for this use case), so it's
>>> not possible to pad the image with black and just crop the relative amount.
>>>
>>> Do you have any advice for the above? Could you adjust the documentation
>>> to reflect the current limitation of the API and possibly update the API to
>>> support this use case?
>>>
>>> Thanks
>>>
>>
>> Ping
>>
>
> second ping
> --
> Vittorio
>
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
>


-- 
Regards,
Kavitha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20180507/8739d90d/attachment.html>