[FFmpeg-devel] [PATCH 1/2 v3] avfilter: add readvitc filter

[wm4]

On Fri, 8 Apr 2016 15:24:56 +0200
Tobias Rapp <t.rapp at noa-archive.com> wrote:

> On 08.04.2016 14:54, Paul B Mahol wrote:
> > On 4/8/16, Tobias Rapp <t.rapp at noa-archive.com> wrote:  
> >> On 08.04.2016 12:48, Carl Eugen Hoyos wrote:  
> >>> Tobias Rapp <t.rapp <at> noa-archive.com> writes:
> >>>  
> >>>>> AV_PIX_FMT_YUV440P? Also J variants...  
> >>>>
> >>>> Good catch, I was lazy and just copied the function from vf_eq.c. The
> >>>> updated patch should contain all pixel formats with planar 8bit luma
> >>>> component.  
> >>>
> >>> Instead of listing the formats, check for pix_fmts
> >>> that are 8bit and planar.  
> >>
> >> That might be an even better idea. Working on v3 of the patch I noticed
> >> that YA8 (which was on the list of v2) is not planar, but NV12 and NV21
> >> (which were missing in v2) have a planar Y.
> >>
> >> Have attached version 3 of the patch which:
> >> - filters the list of all pixel formats dynamically
> >> - supports thr_b and thr_w parameters having the same value
> >> - updates the warning if thr_b == thr_w to print the parameter value
> >> instead of the internal 8-bit value
> >> - has reduced number of parentheses in CRC code
> >>
> >> Regards,
> >> Tobias
> >>  
> >
> > Now, when someone adds 8bit X planar format which is not YUV it will break.  
> 
> It depends on whether the equation "is_yuv_or_gray = (desc->flags & 
> AV_PIX_FMT_FLAG_RGB) == 0)" can be made or not. The comment in 
> libavutil/pixdesc.h made me assume it is safe to do so:
> 
> """
> /**
>   * The pixel format contains RGB-like data (as opposed to YUV/grayscale).
>   */
> #define AV_PIX_FMT_FLAG_RGB          (1 << 5)
> """
> 
> So what has more weight, the aspect of defensive programming or the cost 
> of maintaining a static list?

There are more colorspaces than RGB and YUV.

I'd say either hardcode the list, or introduce libavutil utility
functions which can "classify" a pixfmt in certain ways useful to such
filters.