[x265] [PATCH REVIEW] Generating weighted full-pels in compressCTURows

[Steve Borho]

On Mon, Sep 30, 2013 at 2:40 AM, Shazeb Khan <shazeb at multicorewareinc.com>wrote:

>
>
>
> On Fri, Sep 27, 2013 at 10:19 PM, Steve Borho <steve at borho.org> wrote:
>
>>
>>
>>
>> On Fri, Sep 27, 2013 at 11:30 AM, Jean-Baptiste Kempf <jb at videolan.org>wrote:
>>
>>> On 27 Sep, shazeb at multicorewareinc.com wrote :
>>> > -        X265_FREE(fpelPlane);
>>> > +        X265_FREE(fpelPlane - m_startPad);
>>>
>>> Is this always allowed?
>>>
>>
>> It's not robust, this if statement also needs to verify refPlane is not
>> NULL  applyWeight() also needs to check for earlier malloc failure and
>> early-out.
>>
>
> What shall be the proper way to handle this condition in applyWeight():
> when fpelPlane has no allocation.
>
> One way out is to have a flag in MotionReference object which must be set
> 'false' on malloc fail ('true' by default); and this flag must be checked
> before calling applyweight() and using the weighted pixels.
> But the problem with this approach will be that the condition will stay
> unreported.
>
> Any suggestions?
>

There are two general theories here:

1 - there is no real recovery from a malloc failure.  You have to do your
best to not crash and to communicate the failure back up to the user and
prevent further API calls from crashing.. ie: you must have a safety
breaker that trips and stops the encoder from using incomplete data
structures.

2 - you can pre-allocate all of the memory you will need at encoder
creation so mallocs are not required once the encode gets started.  This
way you can report the malloc error at creation and the application can
react more cleanly.

We should aim for a combination of these.  The former first and then work
towards the latter.

-- 
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20130930/96243474/attachment.html>