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.

ffmpeg-devel mailing list

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to