[FFmpeg-devel] [PATCH] avcodec: add drop_changed_frames

Hendrik Leppkes h.leppkes at gmail.com
Mon Apr 15 11:26:12 EEST 2019


On Mon, Apr 15, 2019 at 8:17 AM Gyan <ffmpeg at gyani.pro> wrote:
>
>
>
> On 15-04-2019 12:17 AM, James Almer wrote:
> > On 4/14/2019 3:29 PM, Hendrik Leppkes wrote:
> >> On Sun, Apr 14, 2019 at 6:50 PM Gyan <ffmpeg at gyani.pro> wrote:
> >>> Implemented this patch
> >>> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241733.html
> >>>
> >>>
> >>>    in libavcodec as suggested by Michael
> >>>
> >> This sure adds a lot of additional fields to the main struct for a
> >> rather specialized feature, that I personally rather see in the hands
> >> of the user of avcodec, not avcodec itself.
> >>
> >> In any case, can't we do this without any new public fields at all?
> >> Put the initial_* state fields into an internal struct (ie.
> >> AVCodecInternal), and expose enabling this through
> >> AVCodecContext->flags or flags2?
> >> That would make me feel much less dirty looking at this patch, personally.
> > +1
> >
> > There has been work to turn public AVCodecContext fields into internal
> > codec options recently as they were too specialized. This commit adds
> > half a dozen of such fields in one go, so it just feels wrong.
>
> Since, for this proposed use, the initial frame information has to be
> recorded, I thought to make them public, so any avcodec user could check
> them for other purposes. Right now, their population is contingent on
> the changed option being set, but that can be taken care of. But no firm
> preference here.
>
> I have a soft preference to keep the first field distinct in avctx, as
> I've seen CLI users to be sloppy both with option placement and setting
> multiple flags correctly for both the same or different target streams.
>

CLI usability problems should be resolved in the CLI tools, not in the
avcodec API, imho.

- Hendrik


More information about the ffmpeg-devel mailing list