On Sun, 15 Nov 2015 12:22:57 +0100 Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Sun, Nov 15, 2015 at 10:40 AM, Muhammad Faiz <mfc...@gmail.com> wrote: > > On Sun, Nov 15, 2015 at 4:24 PM, Hendrik Leppkes <h.lepp...@gmail.com> > > wrote: > >> On Sun, Nov 15, 2015 at 9:51 AM, Muhammad Faiz <mfc...@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 > stay. Agreed. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
