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

Tobias Rapp t.rapp at noa-archive.com
Thu Apr 14 08:49:58 CEST 2016


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?

Regards,
Tobias



More information about the ffmpeg-devel mailing list