[FFmpeg-devel] [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket
nfxjfg at gmail.com
Sun Nov 15 12:44:46 CET 2015
On Sun, 15 Nov 2015 12:22:57 +0100
Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Sun, Nov 15, 2015 at 10:40 AM, Muhammad Faiz <mfcc64 at gmail.com> wrote:
> > On Sun, Nov 15, 2015 at 4:24 PM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> >> On Sun, Nov 15, 2015 at 9:51 AM, Muhammad Faiz <mfcc64 at gmail.com> wrote:
> >>> add AV_PKT_FLAG_FRAME
> >>> add av_packet_encode_frame()
> >>> add av_packet_decode_frame()
> >>> add av_packet_get_frame()
> >>> use pointer to AVFrame instead
> >>> properly padded with AV_INPUT_BUFFER_PADDING_SIZE
> >>> modify wrapped_avframe encoder
> >>> implement wrapped_avframe decoder
> >>> implement wrapped_avframe_audio encoder/decoder
> >>> fix avformat/yuv4mpegenc to use av_packet_get_frame()
> >>> patch attached
> >> We already have 3 different API approaches to pass AVFrames as
> >> AVPackets, we really don't need any more.
> > What are they?
> - The deprecated AVFMT_RAWPICTURE deal, which was a giant hack and is
> luckily leaving us eventually.
> - The "uncoded frame" API introduced in ffmpeg a while ago
> - And now the wrapped_avframe dealy
These should all be replaced with wrapped avframe. (The uncoded frame
API should be deprecated.)
> We really don't need more public API functions to deal with this
> stuff, its already confusing enough as it is.
> Use one of the existing ways to do what you want to do, but don't
> introduce new public API that just exists for lavd/lavfi, where a
> filter pretends to be a "demuxer".
And some other places. ffmpeg.c, where encoding to a raw and writing
to a null output would make fate slower, and y4m, which would become
slower as well.
> Its unlikely to ever be useful outside of this use-case. Public API
> needs to be considered carefully, because once it exists, its here to
More information about the ffmpeg-devel