[FFmpeg-devel] [PATCH] smptebars filter

[Paul B Mahol]

On 8/2/12, Tim Nicholson <nichot20 at yahoo.com> wrote:
> On 01/08/12 12:16, Stefano Sabatini wrote:
>> On date Wednesday 2012-06-20 16:48:37 +0000, Paul B Mahol encoded:
>>> On 6/20/12, Tim Nicholson <nichot20 at yahoo.com> wrote:
>>>> On 20/06/12 09:19, Thierry Foucu wrote:
>>>>> On Wed, Jun 20, 2012 at 9:54 AM, Paul B Mahol <onemda at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Signed-off-by: Paul B Mahol <onemda at gmail.com>
>>>>>> ---
>>>>>>  doc/filters.texi             |   20 ++++
>>>>>>  libavfilter/Makefile         |    1 +
>>>>>>  libavfilter/allfilters.c     |    1 +
>>>>>>  libavfilter/vsrc_smptebars.c |  215
>>>>>> ++++++++++++++++++++++++++++++++++++++++++
>>>>>>  4 files changed, 237 insertions(+), 0 deletions(-)
>>>>>>  create mode 100644 libavfilter/vsrc_smptebars.c
>>>>>>
>>>>>> diff --git a/doc/filters.texi b/doc/filters.texi
>>>>>> index 566fbfc..0c0c490 100644
>>>>>> --- a/doc/filters.texi
>>>>>> +++ b/doc/filters.texi
>>>>>> @@ -3799,6 +3799,26 @@ the @code{mp=geq} filter:
>>>>>>  nullsrc=s=256x256, mp=geq=random(1)*255:128:128
>>>>>>  @end example
>>>>>>
>>>>>> + at section smptebars
>>>>>> +
>>>>>> +Generate SMPTE color bars.
>>>>>>
>>>>>
>>>>>
>>>>> Am i correct to assume that this SMPTE color bar is the SD version.
>>>>>
>>>>> For HD, I though to remember the SMPTE color bar is different.
>>>>> see http://en.wikipedia.org/wiki/File:SMPTE_Color_Bars_16x9.svg
>>>>>
>>>>> If so, should we not call this one SMPTE_SD? or add both into the same
>>>>> filter?
>>>>>
>>>>>
>>>>
>>>> I think bars should be in the correct format for the colorspace
>>>> intended
>>>> with true black at RGB 16  units and true white at 235. (Those are the
>>>> European figures I guess they may differ for 525/60 standards)
>>>
>>> Colors (rainbow and wobnair) are exactly as generated by y4mcolorbars.
>>>
>
> For full range RGB values and 75% bars they look correct to me
>
>>> Other colors like mentioned in comments are just made up and can not
>>> be really reproduced in RGB or YUV(J) colorspace.
>>>
>>> Also drawutils only supports RGB color input.
>>>
>>>>
>>>> ISTR that the blackest black on SMPTE bars is actually 2% below true
>>>> black in order to test for black clipping, but that true back on NTSC
>>>> was 5% up on true black in PAL back in the analogue days....
>>>>
>>>> As for HD bars being different, they certainly look different in HD on
>>>> a
>>>> waveform monitor, but the different colorspace matrix will do that for
>>>> you. I'm not aware of the actual generated RGB levels being different,
>>>> but again this may be different outside of Europe...
>>>>
>>>> Time to dig out the specs again....
>>
>> Updated (against a few patches which still need to be applied), but
>> you get the idea.
>
> Not sure about the PLUGE values though...
> I am used to working 16-235 YUV so may have got some maths wrong but by
> my understanding:-
>
>> +static uint8_t white[4] = { 255, 255, 255, 255 };
>> +static uint8_t black[4] = {   0,   0,   0, 255 };
>
> Whilst, in SMPTE bars, white is 100% black is 7.5%, with blanking at 0%,
> which would give:-
>
>    static uint8_t black[4] = { 19,  19,  19, 255 };
>
>> +
>> +/* made up values */
>> +static const uint8_t neg4ire[4] = {   7,   7,   7, 255 };
>> +static const uint8_t pos4ire[4] = {  17,  17,  17, 255 };
>
> These values would both be brighter than the original "black" above
> (0,0,0) surely?

They are not part of RGB/YUV, they can not be showed in such colorspace
they are completly made up values, and your values will not make them
any better.

>
> Based on my figures I would reckon:-
>
>   static const uint8_t neg4ire[4] = {   9,   9,   9, 255 };
>   static const uint8_t pos4ire[4] = {  29,  29,  29, 255 };
>
>
>> +static const uint8_t i_pixel[4] = { 224,   0,   0, 255 };
>> +static const uint8_t q_pixel[4] = {   0,   0, 176, 255 };
>
> Again these look a little curious to me, the "pure" values only exist in
> YUV land and are often "fudged" by bumping up the Y to avoid negative
> values in RGB land but preserve the phase so it looks correct on a
> vectorscope.
>
> My values are:-
>
>    static const uint8_t i_pixel[4] = {   0,  68, 114, 255 };
>    static const uint8_t q_pixel[4] = {  67,   0, 130, 255 };
>
> Which give the converted CbCr values of  158,95 and 175,148.