[FFmpeg-devel] [PATCH] avdevice/xcbgrab: Improve non-shm performance
Marton Balint
cus at passwd.hu
Fri Dec 6 11:11:54 EET 2019
On Thu, 5 Dec 2019, Kusanagi Kouichi wrote:
> On 2019-12-04 22:32:52 +0100, Marton Balint wrote:
>>
>>
>> On Wed, 4 Dec 2019, Kusanagi Kouichi wrote:
>>
>> > On 2019-12-03 21:25:37 +0100, Marton Balint wrote:
>> > >
>> > >
>> > > On Tue, 3 Dec 2019, Kusanagi Kouichi wrote:
>> > >
>> > > > On 2019-11-19 22:59:56 +0900, Kusanagi Kouichi wrote:
>> > > > > Use AVBufferPool.
>> > >
>> > > You don't need a buffer pool for the non-shm case, you should wrap the XCB
>> > > data in a buffer ref instead. I will reply with a patch that shows how it is
>> > > done, please check if it works correctly, as I am not 100% sure how xcb data
>> > > structures should be allocated/freed.
>> > >
>> >
>> > Is it safe to omit AV_INPUT_BUFFER_PADDING_SIZE bytes padding? My first
>> > version is identical to yours. Valgrind reported no error. But I'm not sure.
>>
>> Strictly speaking it is against the API, but the performance gains IMHO are
>> too big to respect the API requirement blindly. Also I see little chance
>> that it will cause issues, because typically avcodec/rawdec.c will simply
>> reassign the buffer ref to an AVFrame and keep the data untouched. And
>> AVFrame data does not have this requirement. If something breaks, we can
>> always reconsider this or find another solution.
>>
>> Regards,
>> Marton
>
> OK, Then can you commit your patch?
Sure, applied with some minor changes.
Regards,
Marton
More information about the ffmpeg-devel
mailing list