On Mon, 12 Dec 2016 17:31:51 +0100 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Mon, Dec 12, 2016 at 10:06:31AM +0100, wm4 wrote: > > On Sun, 11 Dec 2016 22:20:39 +0100 > > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > > > On Sun, Dec 11, 2016 at 02:00:04PM +0100, wm4 wrote: > > > > On Sun, 11 Dec 2016 00:33:03 -0300 > > > [...] > > > > Here are some brainstormed alternative ideas to adding those ...2() > > > > functions: > > > > - add functions to add side data by type to AVFrames etc. > > > > - provide a generic function that allocates side data by passing the > > > > side data ID to it (would need separate ones for packet and stream > > > > side data) > > > > > > > - unify the side data enums into one (i.e. merge packet and frame side > > > > data), > > > > > > I was wondering previously already why there are multiple enums > > > I think a single enum list would be simpler independant of other > > > things > > > > Unfortunately Libav doesn't seem to have much interest, since it would > > break the API (or at least ABI). Also they don't have many side data > > types that require allocators. > > While it makes sense for us to listen and consider what Libav does, > and we may very well choose to do the same. We could choose to > do something different, if people prefer that ... Well, they have a point: it would require changing ABI at least (and maybe semi-weird hacks to keep the API compatible for a while). We could still do av_allocate_frame_side_data(int id, ...) etc. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
