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

Tobias Rapp t.rapp at noa-archive.com
Fri Apr 15 09:36:43 CEST 2016


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-avfilter-add-readvitc-filter.patch
Type: text/x-patch
Size: 13488 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160415/2828ea1a/attachment.bin>


More information about the ffmpeg-devel mailing list