On 4/15/16, Tobias Rapp <t.r...@noa-archive.com> wrote: > On 14.04.2016 22:29, Michael Niedermayer wrote: >> 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 >> >> [...] > > Have attached an updated patch rebased upon current git master. Took the > chance to add an example to doc/filters.texi. > > Noticed that the libavfilter minor version bump got lost in the merge, > apparently due to commit 8688d3af39e8cd8848e74407998777dd5aad3863. Hope > it is OK? > > Regards, > Tobias >
applied. Thanks! _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
