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?
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
