[FFmpeg-devel] [PATCH]lavc/h264_ps: Check chroma_location limits

[wm4]

On Fri, 24 Mar 2017 07:48:53 -0400
"Ronald S. Bultje" <rsbultje at gmail.com> wrote:

> Hi,
> 
> On Fri, Mar 24, 2017 at 7:40 AM, Ronald S. Bultje <rsbultje at gmail.com>
> wrote:
> 
> > Hi,
> >
> > On Fri, Mar 24, 2017 at 6:23 AM, Carl Eugen Hoyos <ceffmpeg at 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