[FFmpeg-devel] [PATCH] libavutil/libavfilter:add opencl warpper and opencl deshake filter

[Stefano Sabatini]

On date Saturday 2013-03-09 20:47:29 +0800, Wei Gao encoded:
[...]
> In pervious mail, you comment is that openclwrapper should move to
> libavfilter. but our plan is that we will submit opendecode and openencode,
> these are in libavcodec, they will use openclwrapper too. And the next
> OpenCL filter we plan to submit is scale, and we will add some files to
> swscale folder, it will use openclwrapper too. So if we submit the patch, we
> may still remove the openclwrapper to libavutil.

OK, in this case please split the patch in a libavutil and libavfilter
part.

[...]
> > > > > +    if(strlen(filtername) > MAX_FILTER_NAME_LEN) {
> > > > > +        av_log(&openclwrapperutils,AV_LOG_ERROR,"filter name is too
> > > > long\n");
> > > > > +        return;
> > > > > +    }
> > > > > +
> > > >
> >  av_strlcpy(filter_buffer[i].filter_name,filtername,MAX_FILTER_NAME_LEN+1);
> > > > > +    filter_buffer[i].cl_inbuf = cl_inbuf;
> > > > > +    return;
> > > >
> > > > aren't you supposed to return an error in case of too long buffers?
> > > >
> > >
> >
> > > This functions is used to save the OpenCL memory pointer and if the
> > follow
> > > filter is OpenCL filter, it can get the OpenCL buffer as input, it can
> > > avoid copy data between GPU and CPU.So the "cl_inbuf" is the buffer
> > > per-OpenCL filter has created,this function just save the pointer.
> >
> > Yes but what happens if the buffer are too short to contain the copied
> > data?
> >
> Our design is that the buffer will be used as the input parameter to
> filter.and it is read only,so the filter will not copy the data to buffer.

If the error is not fatal, you should just emit a warning
(AV_LOG_WARNING). Anyway I need to have another look at the code
logic, will do with your updated version.

[...]
-- 
FFmpeg = Free and Fast Mind-dumbing Programmable Extreme Guru