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