On Tue, May 5, 2015 at 8:54 PM, Anton Khirnov <[email protected]> wrote: > Quoting Vittorio Giovara (2015-05-05 18:02:34) >> 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 > > Yes, all. > > For any packet side data, you can say > "But the caller might be interested in the side data that was associated > with the packet this frame was decoded into." > This argument is completely independent of what kind of side data it is. > And you can do the reverse too. > >> >> > 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 > > I do not think we should overcomplicate our API to make obscure use > cases simple. >> >> >> 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). >> > > Yes, there is duplication, and yes, something should be done about it. > But I don't think verbatim replacing those fields with a side data > struct is the best solution. > > key_frame/pict_type are the properties of encoded data. They are NOT > properties of raw decoded frames, so IMO it does not make sense to > attach them to frames.
I see what you mean now and believe you're right. So I'll move the side data to lavc and avoid copying it to avframes. The question of the structure name remains. How about AVPacketEncoderParams? It should carry all the properties needed and suggestions received. -- Vittorio _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
