[FFmpeg-devel] [Bulk] Re: [PATCH] smptebars filter

[Tim Nicholson]

On 02/08/12 22:48, Stefano Sabatini wrote:
> On date Thursday 2012-08-02 17:39:19 +0100, Tim Nicholson encoded:

> [...]

> 
> Drawutils convert the color specified in the RGB colorspace to 
> a color in the YUV CCIR colorspace.
> 

Which is the primary source of the problem, it is not actually possible
to create bars to the SMPTE spec (ECR 1-1978) in anything other than YUV
colourspace. This is because the two colour blocks (i_pixel and q_pixel
in your code) are not real colours, but phase shifted (rotated) segments
of the colour burst signal designed to check alignment of the quadrature
chroma decoder. They therefore have UV values but no Y value, and if
converted to RGB colourspace produce negative values. (I presume this is
what Paul was referring to)

In a digital environment pure SMPTE bars are of limited value, but in
case anyone would want to use the signal for the purposes intended
(which they might if they believe them to be a genuine implementation) a
common fudge, and it is a fudge, which means the signal pattern is *not*
to the SMPTE standard but may be used in the same manner, is to add a Y
offset so that the signal is not clipped in the RGB domain. Since the UV
values are correct the signal will look in the right place on a
vectorscope that ignores luma values.

I believe the revised SMPTE RP 219-2002 standard which is suitable for
HD and SD does not suffer fromm these issues, but I do not currently
have a spec for it.


> I don't know where these values come from (I just readapted the code
> to the updated framework), but if you can provide a link to specs and
> a rationale for your proposed values (in RGB or YUV CCIR colorspace)
> that should be enough.

I am not aware of the SMPTE spec being published online, they tend to
charge for copies of their docs. However the following provides a good
general description:-

http://en.wikipedia.org/wiki/SMPTE_color_bars

For more rigorous maths see:-

http://avisynth.org/mediawiki/ColorBars_theory

For a description of how the bars signal is supposed to be used:-

http://spareroommedia.com/video/monitor_setup.html

and for heavy bedtime reading there is a wealth of material at:-

http://www.poynton.com/


My values are based upon:-
0 IRE units= 0; 100 IRE units= 255; RGB

For the pluge section this gives

black= 255*7.5/100 = 19.125    => 19
black-4= 255*3.5/100 = 8.925   =>  9
black+4= 255*11.5/100 = 29.325 => 29

For the Q,-I sections

Using the Rec 601 coefficients (ffmpegs default RGB to YUV matrix)

Q:/  RGB 67,  0, 130 => YUV 46, 175, 148 (after rounding)
-I:/ RGB  0, 68, 114 => YUV 61. 158.  95 (after rounding)

The "correct" values being (see the avisynth page or poynton for
detailed maths)

Q:/  YUV 16, 175,148
-I:/ YUV 16, 158, 95

Which leads to my submission:-


static const uint8_t white[4] = { 255, 255, 255, 255 };
static const uint8_t black[4] = {  19,  19,  19, 255 };

/* pluge pulses */
static const uint8_t neg4ire[4] = {   9,   9,   9, 255 };
static const uint8_t pos4ire[4] = {  29,  29,  29, 255 };

+/* fudged Q/-I */
static const uint8_t i_pixel[4] = {   0,  68, 130, 255 };
static const uint8_t q_pixel[4] = {  67,   0, 130, 255 };



> 
> (And I agree if we call it "SMPTE bars" I'd expect the pattern refers
> to some standard).
...and as we are fudging some values I think we should say so as per my
inline comment above...

> [..]


-- 
Tim