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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
