[Mesa-dev] [PATCH 2/7] st/vdpau: exit gracefully if we fail to create video buffer
Emil Velikov
emil.l.velikov at gmail.com
Mon Aug 19 08:42:37 PDT 2013
On 19/08/13 09:08, Christian König wrote:
> Am 18.08.2013 14:20, schrieb Emil Velikov:
>> On 18/08/13 12:31, Christian König wrote:
>>> Am 17.08.2013 23:51, schrieb Emil Velikov:
>>>> Otherwise we risk causing memory corruption.
>>>>
>>>> v2: forgot the mutex_unlock()
>>>>
>>>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>>> NAK. Failing is actually not correct here, cause we can still make it
>>> work by allocating the video buffer later on decoding or uploading of
>>> image data.
>>>
>> Let me see if I get this right
>>
>> The API dictates that one can create a surface and there is no guarantee
>> that a video buffer will be associated with it, is that correct ?
>
> Actually the API doesn't dictates anything about this (late vs. early
> allocation of buffers), it's more like I want to give the driver control
> over this.
>
Makes sense, thanks for the information.
>> Afaics after creating such a surface anyone can call
>> vlVdpVideoSurfaceGetBitsYCbCr() thus getting a NO_IMPLEMENTATION, but
>> then again who in their right mind would want to do that :)
>
> Returning NO_IMPLEMENTATION in case a surface doesn't have a backing
> store yet probably isn't such a good idea. Just clearing the destination
> buffers to black in vlVdpVideoSurfaceGetBitsYCbCr sound like the valid
> response to this.
>
If you don't mind I'll leave this exercise for a later moment.
Cheers,
Emil
More information about the mesa-dev
mailing list