[FFmpeg-devel] [PATCH] avcodec: add drop_changed_frames
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.
More information about the ffmpeg-devel