Quoting wm4 (2016-02-10 12:03:57) > On Tue, 9 Feb 2016 18:54:37 +0100 > Anton Khirnov <[email protected]> wrote: > > +/** > > + * Get a list of possible source or target formats usable in > > + * av_hwframe_transfer_data(). > > + * > > + * @param hwframe_ctx the frame context to obtain the information for > > + * @param dir the direction of the transfer > > + * @param formats the pointer to the output format list will be written > > here. > > + * The list is terminated with AV_PIX_FMT_NONE and must be > > freed > > + * by the caller when no longer needed using av_free(). > > + * If this function returns successfully, the format list > > will > > + * have at least one item (not counting the terminator). > > + * On failure, the contents of this pointer are unspecified. > > + * @return 0 on success, a negative AVERROR code on failure. > > + */ > > +int av_hwframe_transfer_get_formats(AVBufferRef *hwframe_ctx, > > + enum AVHWFrameTransferDirection dir, > > + enum AVPixelFormat **formats); > > I'm wondering how this works on vaapi. vaapi has many formats and at > least 2 methods to copy data from/to hw frames, and I _think_ they all > vary in efficiency and whether they work at all. >
You mean derive versus get? In my unfinished local vaapi implementation I'm testing whether derive works at init and then prefer it if it does. If we have the proper streaming memcpy, it should work well, right? Also, vaGetImage insists on using vaapi-allocated memory, which means _two_ copies in this API. I've also been considering additional functions that would map a frame from one type to a different one. Typically from an hwaccel format to a normal one, but possibly also the other way around or from one hwaccel to another. But since I have no immediate use for it, I didn't implement it at this point. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
