On Sun, 18 Oct 2015 14:54:58 +0200 Anton Khirnov <[email protected]> wrote:
> Quoting wm4 (2015-10-18 14:44:02) > > On Sun, 18 Oct 2015 14:36:53 +0200 > > Luca Barbato <[email protected]> wrote: > > > > > On 18/10/15 11:34, Anton Khirnov wrote: > > > > And even if, as you say, the function did not need any changes beyond > > > > renaming, then we should not touch them at all. Renaming (if not adding > > > > av prefixes to unprefixed stuff) is pretty much cosmetics, and I do not > > > > think it is a sufficient reason to break API. We're annoying our > > > > downstreams quite enough with all the other breakage. > > > > > > I'll prepare a set with > > > > > > - the new API: > > > av_packet_alloc() > > > av_packet_free() > > > av_packet_resize() > > > av_packet_move_ref() (I see at least 1 use for it) > > > - deprecations: > > > av_dup_packet() > > > av_free_packet() > > > av_grow_packet() > > > av_shrink_packet() > > > av_init_packet() > > > > > > - two renames w/out deprecation > > > avio_get_packet() > > > avio_append_packet() > > > > > > Sounds good enough for you? > > > > At least av_packet_free and av_free_packet are the same? > > No, av_free_packet() is equivalent to av_packet_unref(), so it only > frees the data and side data. av_packet_free() would also free the > packet struct itself. > Right. Confused it with av_packet_unref(). _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
