On Sun, Nov 15, 2015 at 6:44 PM, wm4 <nfx...@gmail.com> wrote: > 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.
If someone could make -filter_complex available in ffplay, this hack in lavd/lavfi is unnecessary, instead we use -filter_complex option. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
