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

Stefano Sabatini stefasab at gmail.com
Fri Aug 3 16:02:53 CEST 2012


On date Friday 2012-08-03 08:59:56 +0100, Tim Nicholson encoded:
> 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...

Patch updated against the proposed values. In order to avoid the Q/-I
color "fudge" we could find some hack to tell ff_draw_color() to
accept YUV values and convert them to RGB colorspace, but I'm not sure
I'm willing to do the work...
-- 
FFmpeg = Friendly and Forgiving Martial Puristic Elfic Gem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-lavfi-add-smptebars-source.patch
Type: text/x-diff
Size: 7578 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120803/f8f0edcb/attachment.bin>


More information about the ffmpeg-devel mailing list