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
_______________________________________________
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".
