Marton Balint (12020-04-06): > The same goal can be achieved using the WRAPPED_AVFRAME codec with the > existing > API.
These two APIs are somewhat redundant, but we need to discuss which one we want to keep. WRAPPED_AVFRAME is nice because it goes through the normal code path, and therefore requires no exception. But on the other hand, it requires many allocations and de-allocations, which is not good since the purpose of these API was to be more efficient: if the application has a frame, which is the most likely, it's more efficient to just pass it. And it's also simpler for the application, less code, less bugs, less maintenance. My opinion: merge the two features, keep the simpler code when the two overlap: - Keep the WRAPPED_AVFRAME codec and its encoder/decoder pair, for when generic code expects an AVPacket. - For muxers implementations, keep the write_uncoded_frame callback, it's simpler. If a packet with WRAPPED_AVFRAME arrives, have the framework de-wrap the frame and call write_uncoded_frame. - Let applications give uncoded unwrapped frames directly. It's simpler, it's more efficient, it's more type-safe. - Possibly later, introduce the symmetric read_uncoded_frame callback. > > Signed-off-by: Marton Balint <c...@passwd.hu> > --- > doc/APIchanges | 4 ++++ > libavdevice/alsa_enc.c | 4 ++++ Any way, I don't think we should deprecate something when we have not yet moved our code to its replacement. You can count on me for porting ALSA, when we have decided in which direction we go. > libavdevice/opengl_enc.c | 4 ++++ > libavdevice/pulse_audio_enc.c | 4 ++++ > libavdevice/version.h | 4 ++-- > libavdevice/xv.c | 4 ++++ > libavformat/avformat.h | 7 +++++++ > libavformat/internal.h | 2 ++ > libavformat/mux.c | 16 ++++++++++++++++ > libavformat/uncodedframecrcenc.c | 6 ++++++ > libavformat/version.h | 6 +++++- > 11 files changed, 58 insertions(+), 3 deletions(-) Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
