[FFmpeg-devel] [PATCH] smptebars filter

[Paul B Mahol]

On 8/2/12, Tim Nicholson <nichot20 at yahoo.com> wrote:
> On 02/08/12 17:04, Paul B Mahol wrote:
>> 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.
>>
>
> Why are they "completly made up values"? How can a standard test pattern
> contain values that cannot be represented in at least one of the
> colourspaces?
>
> SMPTE bars are supposed to contain a pluge pulse with sections that are
> supposed to be 4 IRE units above and below the standard NTSC black level
> of 7.5 IRE units which it is perfectly possible to represent in both RGB
> and YUV colourspace.
>
> The naming, and placing in the drawn image suggests these constants are
> meant to represent these sections and I have suggested RGB values to
> match the required +/-4 values.
>
> If we really cannot generate the correct values for these parts of the
> test signal we really should not refer to them as SMPTE bars.
>
> Sorry if I have completely misunderstood, but I can't at the moment see
> what I am missing.

For the record I do not really care what colors will be picked....