[FFmpeg-devel] [PATCH v2 1/3] avcodec/avpacket: extend AVFrame wrapping in AVPacket

[Muhammad Faiz]

On Sun, Nov 15, 2015 at 6:44 PM, wm4 <nfxjfg at gmail.com> wrote:
> 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
>> stay.
>
> Agreed.

If someone could make -filter_complex available in ffplay,
this hack in lavd/lavfi is unnecessary, instead we use -filter_complex
option.