On Fri, 24 Mar 2017 07:48:53 -0400 "Ronald S. Bultje" <[email protected]> wrote:
> Hi, > > On Fri, Mar 24, 2017 at 7:40 AM, Ronald S. Bultje <[email protected]> > wrote: > > > Hi, > > > > On Fri, Mar 24, 2017 at 6:23 AM, Carl Eugen Hoyos <[email protected]> > > wrote: > > > >> there are several similar cases there. > > > > > > That is classically how ff_ symbols became public API. Please don't use > > that argument ever again. > > > > Btw, I'm not arguing with your suggestion that maybe _NB should be > redefined to be part of our API but the value in runtime libavutil may be > bigger. It may or may not be a good idea, I don't know. > > I'm merely arguing with the point that since we violate the API already, > it's OK to violate it some more. I don't think this is even needed here: - the chroma loc values obviously mirror the h264 standard, so you simply get the bitstream value (including new extension that might be added in the future) - everything outside libavutil has to handle the situation that there are unknown chroma loc values (that can be higher than AVCHROMA_LOC_NB at the time of compilation) - libavutil itself handles out of bounds chroma loc values where it matters _______________________________________________ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
