On Fri, 24 Mar 2017 07:48:53 -0400 "Ronald S. Bultje" <rsbul...@gmail.com> wrote:
> Hi, > > On Fri, Mar 24, 2017 at 7:40 AM, Ronald S. Bultje <rsbul...@gmail.com> > wrote: > > > Hi, > > > > On Fri, Mar 24, 2017 at 6:23 AM, Carl Eugen Hoyos <ceffm...@gmail.com> > > 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 ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
