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

[Michael Niedermayer]

On Thu, Apr 14, 2016 at 08:49:58AM +0200, Tobias Rapp wrote:
> On 08.04.2016 17:01, Tobias Rapp wrote:
> >On 08.04.2016 15:24, Tobias Rapp 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?
> >
> >Attached patch v4 contains the more defensive static-pixfmt-list
> >approach together with the threshold changes from v3.
> 
> Any further comments or suggestions? Who feels responsible for
> pushing this (and the FATE test after uploading the sample) in case
> nobody objects?

i can upload a sample
where can i find the sample ?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160414/3e9949b0/attachment.sig>