On Tue, May 5, 2015 at 3:25 PM, Anton Khirnov <[email protected]> wrote: > Quoting Vittorio Giovara (2015-05-05 15:19:44) >> On Sat, May 2, 2015 at 5:50 AM, Anton Khirnov <[email protected]> wrote: >> > Quoting Vittorio Giovara (2015-05-02 01:17:17) >> >> Add an helper function and a compatibility layer for exporting >> >> information through coded_frame. >> >> >> >> The compression data is exported to the decoded frame, offering a direct >> >> correspondece between the packet and the frame properties. >> >> >> >> Signed-off-by: Vittorio Giovara <[email protected]> >> >> --- >> >> doc/APIchanges | 5 +++++ >> >> libavcodec/avcodec.h | 6 ++++++ >> >> libavcodec/internal.h | 5 +++++ >> >> libavcodec/utils.c | 33 +++++++++++++++++++++++++++++++++ >> >> libavcodec/version.h | 4 ++-- >> >> libavformat/dump.c | 24 ++++++++++++++++++++++++ >> >> libavutil/frame.h | 7 +++++++ >> >> libavutil/metadata.h | 20 ++++++++++++++++++++ >> >> libavutil/version.h | 2 +- >> >> 9 files changed, 103 insertions(+), 3 deletions(-) >> >> >> > >> > * why is there a frame side data type? This stuff only applies to >> > compressed packets. >> >> because you might be interested in the compression properties that >> came from the packet. > > By that logic, every kind of side data should have both a frame and > packet flavour.
side data for everyone \o/ well not all, but i see no problem in a little ovelapping between packet and frame, they are the same being from two different point of view > And you can already associate a packet to a decoded frame via dts or > reordered_opaque if you really want to. yes but checking an avframe side data is simpler than mapping with dts or reordered_opaque imho >> It's kind-of already implemented the equivalent fields in avframe too. >> > > Because side data didn't exist at the time those fields were added. > I'm not sure lavc even used AVPacket back then. Well all i know is that there is some duplication between avpacket, avcodeccontext and avframe, it'd be nice if there was a unified way to access all these fields; i think my suggested approach covers that requirement and it's future proof (eg a decoder could just rely on avstats rather than setting key_frame and pict_type manually). >> > * the name 'AVStats' is incredibly generic and also misleading, since >> > there is no real statistics in it, just some per-packet information. >> > AVPacketCompressionParam might work, but is still kind of ugly and >> > long. Better suggestions welcome. >> >> AVCompressionProps? > > I think the name should somehow reflect the fact that this is per-packet > information. AVCompressionProps could just as well mean global > encoder properties. I guess we first need to decide whether this side data should be shared with avframes or not. Maybe just AVCompressionParam could do for now. Thoughts? -- Vittorio _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
