Author Topic: Book on SMPTE SDI Protocol?  (Read 2238 times)

0 Members and 1 Guest are viewing this topic.

Offline jakubhladik1Topic starter

  • Newbie
  • Posts: 7
  • Country: us
Book on SMPTE SDI Protocol?
« on: May 25, 2023, 12:54:03 pm »
Hello,

I have to implement SDI Tx and Rx in an FPGA and reading the SMTPE specification proved to be difficult as I find myself in an endless loop of trying to get yet another referenced specification. The entire SDI specification set is like a LEGO kit, except the only way to purchase it is one LEGO brick at a time.

Is there any book that presents the SDI protocol in a comprehensive way? Or does the proprietary nature of this specification prohibit someone from writing a comprehensive book?
« Last Edit: May 25, 2023, 12:57:05 pm by jakubhladik1 »
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 4493
  • Country: au
    • send complaints here
Re: Book on SMPTE SDI Protocol?
« Reply #1 on: May 25, 2023, 11:19:14 pm »
There is a reason SDI IP is expensive, it's not easy! SDI is layers of complexity built up over decades forever wrapping the legacy/older parts which is why it is spread across so many different standards. Also the majority of possibilities covered in the standards is never seen/used in the real world. Complexity is high enough that it's unlikely a single person could build a widely compatible solution in less than years.

I have not come across any reference books on the subject.
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: Book on SMPTE SDI Protocol?
« Reply #2 on: May 26, 2023, 09:52:24 am »
The basic SDI wire protocols are not that complex, and most of the FPGA vendors have IP blocks for handing the line side of things (Usually line to 20 bit parallel or such with clock recovery and at least some format detection).

There is a trap in that depending on the frame rate (Blame NTSC here) you usually need a serdes clock at either 148.5 or 148.35MHz depending on the rate being integer or 1000/1001, which is aggravating.

The devil is in all the stuff that you can stuff into the HANC and VANC time, that shit is just plain annoying and sprawled across dozens of standards most of which are never used (Or even supported) in practice.

On the physical layer watch the pathological conditions, the coupling caps need to be annoyingly large to make the thing work in the worst case low frequency condition.  On a related nots, for SD at 270Mb/s you often have to oversample because the serdes block in the FPGA just does not go slow enough.

As far as documentation goes, I am not aware of a 'collected SDI standards' set, but some of the test gear vendors have very useful white papers on how bits of this work, as do some of the FPGA vendors as a side effect of their IP cores.
 

Offline jakubhladik1Topic starter

  • Newbie
  • Posts: 7
  • Country: us
Re: Book on SMPTE SDI Protocol?
« Reply #3 on: May 26, 2023, 01:11:51 pm »
There is a reason SDI IP is expensive, it's not easy! SDI is layers of complexity built up over decades forever wrapping the legacy/older parts which is why it is spread across so many different standards. Also the majority of possibilities covered in the standards is never seen/used in the real world. Complexity is high enough that it's unlikely a single person could build a widely compatible solution in less than years.

I have not come across any reference books on the subject.

Yes, I agree. 100% compatible solution would take a very long time and would require a ton of expensive and specialized test equipment. Luckily, I do not have to implement an IP that is compatible 100%. This is for avionics application where only a subset of the SDI spec is applicable.

The basic SDI wire protocols are not that complex, and most of the FPGA vendors have IP blocks for handing the line side of things (Usually line to 20 bit parallel or such with clock recovery and at least some format detection).

Thank you. I noticed both Altera and Xilinx have a pretty good documentation of their IPs. I am working on the receiver first. I am using the vendor XCVR IP outputting raw data and then wrote custom code to the NRZI->NRZ and descrambling. I also finished a block for the TRS word alignment. Now I am stuck not knowing how to tell what format is being sent to know how to parse the pixel data into pixels. Based on the specs, it seems like the format data is carried in the ancillary data during blanking. I am looking into decoding ancillary data before writing an FSM to pull the pixel data out depending on the format.

There is a trap in that depending on the frame rate (Blame NTSC here) you usually need a serdes clock at either 148.5 or 148.35MHz depending on the rate being integer or 1000/1001, which is aggravating.

On the Rx side, I can set the reference clock to the mid-point between the two and then the XCVR CDR's 1000ppm tolerance will cover both rates and still give me a little bit of margin. If Tx is required, there is no way around having two reference clocks, at least not with integer XCVR PLLs.

The devil is in all the stuff that you can stuff into the HANC and VANC time, that shit is just plain annoying and sprawled across dozens of standards most of which are never used (Or even supported) in practice.

I have no idea what HANC and VANC time is. It will probably be a surprise as I try to understand the ancillary data side of the specification.

On the physical layer watch the pathological conditions, the coupling caps need to be annoyingly large to make the thing work in the worst case low frequency condition.  On a related nots, for SD at 270Mb/s you often have to oversample because the serdes block in the FPGA just does not go slow enough.

That was the first thing I wondered about when I saw SDI input schematic -- the 4.7 uF caps for AC coupling. I wondered why the well-known "rule of thumb" is being broken there and quickly learned the pathological signals are difficult to pass through something like 100 nF.

As far as documentation goes, I am not aware of a 'collected SDI standards' set, but some of the test gear vendors have very useful white papers on how bits of this work, as do some of the FPGA vendors as a side effect of their IP cores.

FPGA vendor IP documentation has been a great source of comprehensive documentation on SDI so far. I will check out test gear vendors.
« Last Edit: May 26, 2023, 01:39:05 pm by jakubhladik1 »
 

Offline RichardS

  • Newbie
  • Posts: 1
  • Country: gb
Re: Book on SMPTE SDI Protocol?
« Reply #4 on: May 28, 2023, 08:30:50 am »
Google for xapp514. I don’t think it’s on Xilinx’s site anymore but there are copies out there.
 
The following users thanked this post: jakubhladik1

Offline Forty-Bot

  • Contributor
  • Posts: 14
  • Country: us
 
The following users thanked this post: jakubhladik1

Offline sd

  • Supporter
  • ****
  • Posts: 42
  • Country: ro
Re: Book on SMPTE SDI Protocol?
« Reply #6 on: May 28, 2023, 06:48:18 pm »
csdn.net and baidudownloader might help.
 

Offline Neomys Sapiens

  • Super Contributor
  • ***
  • Posts: 3268
  • Country: de
Re: Book on SMPTE SDI Protocol?
« Reply #7 on: May 29, 2023, 12:27:15 am »
This should have something:

Charles Poynton: Digital Video and HDTV Algorithms and Interfaces. Morgan Kaufmann Publishers, San Francisco 2003, ISBN 1-55860-792-7

Video coding standards: AVS China, H.264/MPEG-4 PART 10, HEVC, VP6, DIRAC and VC-1, Springer, 2014 by K.R. Rao & Do Nyeon Kim & Jae Jeong Hwang (auth.)
 
The following users thanked this post: jakubhladik1

Offline Scrts

  • Frequent Contributor
  • **
  • Posts: 797
  • Country: lt
Re: Book on SMPTE SDI Protocol?
« Reply #8 on: June 01, 2023, 04:41:04 pm »
Do you need SD-SDI or higher SDI? SD might be easy to implement, but beyond that, I'd just buy IP core from Xilinx or Intel...
 

Offline jakubhladik1Topic starter

  • Newbie
  • Posts: 7
  • Country: us
Re: Book on SMPTE SDI Protocol?
« Reply #9 on: June 05, 2023, 04:26:19 pm »
I need HD-SDI + 3G-SDI, 6G-SDI as a bonus if I can run the 20-bit data path at 297 MHz. This is for DO-254 avionics application where we need to prove to the govt authorities that the code is safe. Very difficult to do with 3rd-party code, impossible to do with encrypted IP code. I got Rx IP working, I just need to add decoding of ancillary data to recognize whether the format being received is RGB or YCbCr and automatically switch between two different pixel unpacking and color space conversion. Xilinx XAPP514 has been extremely helpful.

On another note, is it expected that 10-10-10 bit RGB 4:4:4 -> 10-10-10 bit YCbCr 4:4:4 -> 10-10-10 bit RGB 4:4:4 conversion is lossy? I noticed due to rounding to integer in the color space conversion (ITU BT.709), the worst case error is the original component +/- 2 (+/- 1 when going from RGB -> YCbCr and another +/- 1 when converting back). I did not expect it but it makes sense in terms of the math. I expect 8-bit RGB -> 10-bit YCbCr -> 8-bit RGB to be lossless as there are enough bits to carry the "fractional" portions of the converted color value without rounding.

I've tried a couple values with my fixed-point decimal color converter and these are the results:

RGB [255, 0, 0] -> YCbCr [54, 482, 643] -> RGB [256, 0, 0]
RGB [940, 64, 64] -> YCbCr [250, 409, 960] -> RGB [940, 64, 63]
RGB [0, 255, 0] -> YCbCr [182, 412, 394] -> RGB [0, 254, 1]

Note that 255 is not the maximum value here, I just used it to show the integer rounding error.
« Last Edit: June 05, 2023, 04:56:09 pm by jakubhladik1 »
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 4493
  • Country: au
    • send complaints here
Re: Book on SMPTE SDI Protocol?
« Reply #10 on: June 05, 2023, 10:43:34 pm »
I expect 8-bit RGB -> 10-bit YCbCr -> 8-bit RGB to be lossless as there are enough bits to carry the "fractional" portions of the converted color value without rounding.
You'd expect wrong! even with 16 bit intermediaries it won't be lossless in most implementations.
 

Offline Scrts

  • Frequent Contributor
  • **
  • Posts: 797
  • Country: lt
Re: Book on SMPTE SDI Protocol?
« Reply #11 on: June 05, 2023, 11:06:49 pm »
I need HD-SDI + 3G-SDI, 6G-SDI as a bonus if I can run the 20-bit data path at 297 MHz. This is for DO-254 avionics application where we need to prove to the govt authorities that the code is safe. Very difficult to do with 3rd-party code, impossible to do with encrypted IP code. I got Rx IP working, I just need to add decoding of ancillary data to recognize whether the format being received is RGB or YCbCr and automatically switch between two different pixel unpacking and color space conversion. Xilinx XAPP514 has been extremely helpful.

On another note, is it expected that 10-10-10 bit RGB 4:4:4 -> 10-10-10 bit YCbCr 4:4:4 -> 10-10-10 bit RGB 4:4:4 conversion is lossy? I noticed due to rounding to integer in the color space conversion (ITU BT.709), the worst case error is the original component +/- 2 (+/- 1 when going from RGB -> YCbCr and another +/- 1 when converting back). I did not expect it but it makes sense in terms of the math. I expect 8-bit RGB -> 10-bit YCbCr -> 8-bit RGB to be lossless as there are enough bits to carry the "fractional" portions of the converted color value without rounding.

I've tried a couple values with my fixed-point decimal color converter and these are the results:

RGB [255, 0, 0] -> YCbCr [54, 482, 643] -> RGB [256, 0, 0]
RGB [940, 64, 64] -> YCbCr [250, 409, 960] -> RGB [940, 64, 63]
RGB [0, 255, 0] -> YCbCr [182, 412, 394] -> RGB [0, 254, 1]

Note that 255 is not the maximum value here, I just used it to show the integer rounding error.

Lossy for the machine? Or human eye? The application here is to deliver high resolution camera data into the airplane?
 

Offline jakubhladik1Topic starter

  • Newbie
  • Posts: 7
  • Country: us
Re: Book on SMPTE SDI Protocol?
« Reply #12 on: June 06, 2023, 12:46:09 pm »
Lossy for the machine? Or human eye? The application here is to deliver high resolution camera data into the airplane?

Lossy for the machine, just thinking ahead for verification of expected values. Correct, camera feed going to a display.
« Last Edit: June 06, 2023, 04:17:50 pm by jakubhladik1 »
 

Offline jakubhladik1Topic starter

  • Newbie
  • Posts: 7
  • Country: us
Re: Book on SMPTE SDI Protocol?
« Reply #13 on: June 06, 2023, 12:54:46 pm »
I expect 8-bit RGB -> 10-bit YCbCr -> 8-bit RGB to be lossless as there are enough bits to carry the "fractional" portions of the converted color value without rounding.
You'd expect wrong! even with 16 bit intermediaries it won't be lossless in most implementations.

Thank you for pointing this out.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf