On 14/10/15 14:45, wm4 wrote: > On Wed, 14 Oct 2015 14:39:31 +0200 > Luca Barbato <[email protected]> wrote: > >> On 14/10/15 11:33, Vittorio Giovara wrote: >>> This structure served as a bridge between data pointers and frames, but >>> it suffers from several limitations: >>> - it is not refcounted and data must be copied to every time >>> - it cannot be expanded without ABI break due to being used on the stack >>> - its functions are just wrappers to imgutils which add a layer of >>> unneeded indirection, and maintenance burden >>> - it allows hacks like embedding uncompressed data in packets >>> - its use is often confusing to our users >>> >>> AVFrame provides a much better API, and, if a full blown frame is not >>> needed, it is just as simple and more straightfoward to use data and >>> linesize arrays directly. >>> >>> Signed-off-by: Vittorio Giovara <[email protected]> >>> --- >>> libavcodec/avcodec.h | 50 >>> +++++++++++++++++++++---------------------------- >>> libavcodec/avpicture.c | 3 ++- >>> libavcodec/imgconvert.c | 2 ++ >>> 3 files changed, 25 insertions(+), 30 deletions(-) >> >> Ok, I'll add few helpers to avframe later. > > Which helpers?
Probably wrapper around av_image_copy_to_buffer to make Derek happier even if `av_frame_image_to_buffer` sounds horrible and an `av_frame_to_buffer` would require to make av_samples_copy too smart. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
