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

[Paul B Mahol]

On 4/15/16, Tobias Rapp <t.rapp at 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.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?
>>
>> 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!