On Mon, Apr 15, 2019 at 8:17 AM Gyan <ffm...@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 <ffm...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
