On Mon, 8 Feb 2016 13:56:57 +0000 Mark Thompson <s...@jkqxz.net> wrote:
> ... > >> +/** Map a surface so that it can be operated on by the CPU. > >> + * > >> + * This may need to copy the frame data between some sort of external > >> memory > >> + * and normal CPU-addressable memory. The copy-in will only take place if > >> + * read access was requested. > >> + * > >> + * @param frame AVFrame to map. Must have been allocated in an > >> + * @ref AVVAAPISurfacePool > >> + * @param flags A set of AV_VAAPI_MAP flags, ored together. > >> + * @return Zero on success, or negative error code. > >> + */ > >> +int av_vaapi_map_frame(AVFrame *frame, int flags); > > > > I know I've stared at the implementation for this in the few previous > > patch iterations, but just looking at this it's not clear to me at all > > what the input and output is. > > > > So the input is a PIX_FMT_VAAPI AVFrame. And on output, this is > > replaced with a "software" AVFrame or what? What happens on unmap? Is > > it magically undone? What happens with the vaapi frame reference? > > > > Maybe it would be better to add a separate AVFrame argument, into which > > the surface is mapped. > > This function is the lowest level mapping for people who know exactly what > they > are doing (especially wrt memory types). The input is the AV_PIX_FMT_VAAPI > AVFrame with buf[0,1] giving the mapping to a surface. The output is the > same > frame with data[0,1,2] and linesize[0,1,2] filled in to use, but nothing else > about the frame changed. Unmap removes the mapping along with the data and > linesize values. I'll clarify how it works in the comment. Still questionable. What if a mapped AVFrame requires all 4 planes? Then data[3] would be overwritten, even though it normally contains the surface ID. > If you think there should be a pair of functions mapping/unmapping to/from a > distinct AVFrame (which would call these two) then I would prefer to add that > separately. I'd say so. > >> + > >> +/** Unmap a surface after operating on it with the CPU. > >> + * > >> + * If the frame data was copied and write access was requested, this will > >> copy > >> + * back to external memory. > >> + */ > >> +int av_vaapi_unmap_frame(AVFrame *frame); > >> + > >> +/** Copy data from memory to a surface. > >> + * > >> + * The size and format of the source must match the underlying format of > >> the > >> + * surface. > >> + */ > >> +int av_vaapi_copy_to_surface(AVFrame *dst, const AVFrame *src); > >> + > >> +/** Copy data from a surface to memory. > >> + * > >> + * The size and format of the destination must match the underlying > >> format of > >> + * the surface. > >> + */ > >> +int av_vaapi_copy_from_surface(AVFrame *dst, AVFrame *src); > >> + > >> + > >> +/** Given a libva fourcc, return the corresponding pixel format. */ > >> +enum AVPixelFormat av_vaapi_pix_fmt(unsigned int fourcc); > >> +/** Given a pixel format, return the corresponding libva fourcc. */ > >> +unsigned int av_vaapi_fourcc(enum AVPixelFormat pix_fmt); > >> +/** Given a libva fourcc, return the associated pipeline chroma format. */ > >> +unsigned int av_vaapi_rt_format(unsigned int fourcc); > >> + > >> +/** Given a pixel format, return the corresponding libva image format. > >> + * > >> + * This uses vaQueryImageFormats(), so results need not be exactly > >> equivalent > >> + * between different drivers. > >> + */ > >> +int av_vaapi_get_image_format(AVVAAPIHardwareContext *hw_ctx, > >> + enum AVPixelFormat pix_fmt, > >> + VAImageFormat *image_format); > >> + > >> +/** @} */ > >> + > >> +#endif /* AVCODEC_VAAPI_SUPPORT_H */ > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
