On Tue, 15 Apr 2014 14:54:19 +0200 Luca Barbato <[email protected]> wrote:
> On 15/04/14 14:21, wm4 wrote: > > On Tue, 15 Apr 2014 05:09:59 +0200 > > Vittorio Giovara <[email protected]> wrote: > > > >> On Mon, Apr 14, 2014 at 3:29 PM, Roman Savchenko <[email protected]> wrote: > >>> Hi All, > >>> For first I add AV_FRAME_DATA_MB_TYPE and AV_FRAME_DATA_MOTION_VAL in > >>> AVFrameSideData enum. > >> > >> So far so good. > >> > >>> For second i try to decide what type (or rather copy) in side data I > >>> should use. Because If I'll use AVBufferRef I must (should I?) to ref with > >>> av_buffer_ref. But it will provide a allocation for AVBufferRef and > >>> AVFrameSideData will provide allocation for AVBufferRef too. It'll not be > >>> a problem if I will copy by value. > >> > >> the "data" field can be anything, you can put an AVBufferRef. If you > >> need to use the values directly you can just memcpy it (I think) but > >> if you want to use it normally you'll have to ref/unref it when you > >> get it from get_side_data. Sorry I can't help you further about > >> AVBufferRef as i'm not much familiar with those. > > > > I don't think this will really work. Side data can not participate in > > reference counting - it's copied when a AVFrame is referenced, and it > > is always copied with memcpy. You could probably attempt to stuff it > > into the AVFrame.extended_buf array, but then it still won't work, > > because referencing an AVBufferRef creates a newly allocated object, so > > the pointer in the side data will become outdated. > > > > You could do it if something else explicitly frees the side data > > AVBufferRef, but that would require changing every single API user. > > > > I think would be easier to mark this side-data as refcounted and act > accordingly with a proper incref and a proper destructor and such in the > normal av_frame_unref. OK, but that would IMO be a big API change. Until now, a user could always transfer side data as byte arrays. Keep in mind that not all downstream users use AVFrame outside of their libavcodec glue code. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
