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.r...@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?
tried to apply the patch locally, but fails Applying: avfilter: add readvitc filter fatal: sha1 information is lacking or useless (doc/filters.texi). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 avfilter: add readvitc filter When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
