On 10/16/2017 07:36 PM, wm4 wrote: > On Mon, 16 Oct 2017 19:28:27 +0800 > Xiaolei Yu <dreifachst...@gmail.com> wrote: > >> On 10/03/2017 09:15 PM, wm4 wrote: >>> From: Anton Khirnov <an...@khirnov.net> >>> >>> Use the AVFrame.opaque_ref field. The original user's opaque_ref is >>> wrapped in the lavc struct and then unwrapped before the frame is >>> returned to the caller. >>> >>> This new struct will be useful in the following commits. >>> >> >> How about using AVFrame::buf[]? > > My local crash-fix hack for videotoolbox actually uses buf[] for this > purpose, but it won't work in general, because video data might need > it. Also that would have exactly the same problems as opaque_ref. > Actually, all approaches will have exactly the same problems as > opaque_ref, but michael doesn't get it.
I think handling foreign memory with a cpu-centric api will always be kinda awkward. But using AVFrame::buf[] is more natural if we treat them as a family of cpu-unaddressable images. Also it would be great (in the future) to allow users to pass them around without a round trip to the main memory. > _______________________________________________ > 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
