[FFmpeg-devel] [PATCH] smptebars filter

[Tim Nicholson]

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?

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.

-- 
Tim