[FFmpeg-devel] [PATCH v6 1/6] libavcodec: VAAPI support infrastructure

[wm4]

On Mon, 8 Feb 2016 13:56:57 +0000
Mark Thompson <sw at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel