The BT656 specification (parallel) mentions a pixel clock of 27MHz.
However, every pixel consists of:
8 bits Y.
8 bits Cb.
8 bits Cr.
So every pixel consists of data from 3 consecutive trasactions. This makes the actual pixel rate 3 time slower than the nominal pixel clock.
BT656 can receive analog signals terminated by 75 Ω with a return loss of at least 15 dB over a frequency range of 5-270 MHz.
This analog can be generated by a 3 port color DAC at the pixel rate. not slower or faster.
Therefore actual pixel rate is just number of pixels like 800x600 x VS rate, where a pixel is 3 colors with 3 parallel ports driving the pixel color signals
I've never used the BT656 but YCbCr isn't structurally much different from RGB. Y is the luminance signal so having it available in it's own right is sometimes useful. Cb and Cr are 'difference signals', in other words 'Cb' is the amount by which the Y and blue signals are different and 'Cr' is the difference between Y and red. The green isn't included or needed as it can be mathematically determined by subtracting the blue and red from the total Y (G=Y-R-B). As the levels and resolutions need to be similar I think the same bit structure will be used. There are variations on the theme though!
Why don't you read the full BT656 specification, it's quite clear I think.
The samples represent a multiplexed data stream, the sequence is Y,Cb,Y,Cr
So you get an effective Y (luminance) sample rate of 13.5 MS/s and a C (color) sample rate of 6.25 MS/s, corresponding to the different bandwidth of luminance and chrominance signals in analog TV. Also the meaning of Cb and Cr as difference signals is the same as in analog color TV.
I have. Perhaps I missed something but it's not very clear about how many bytes build a single pixel. I think that every pixel consists of Y and either Cb or Cr. Y is always present while Cb and Cr interchange between pixels. I.E: If pixel 0 got Y and Cb, the adjacent pixel will get Y and Cr. So data for a single pixel is negotiated over 2 BT656 trasactions. 1 pixel = 2 bytes.
If you want to calculate a pixel rate, yes. Pixel rate is 13.5 MHz, two consecutive pixels are using the same chroma information.
In a real video system, the chroma channel might be low-pass filtered for interpolation.
Like this?
Pixel 0 (first pixel) gets Cr(0) and Y(0) - it doesn't get a Cb byte.
Pixel 1 (the following after 0) Cb(1) and Y(1) - it doesn't get a Cr byte.
Pixel 2 (the following after 1) gets Cr(1) and Y(2) - it doesn't get a Cb byte.
etc...