[FFmpeg-devel] [PATCH] smptebars filter

Tim Nicholson nichot20 at yahoo.com
Thu Aug 2 18:39:19 CEST 2012


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.

>>
>> 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.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 


-- 
Tim




More information about the ffmpeg-devel mailing list