Changes between Initial Version and Version 1 of Yocto/Video_In


Ignore:
Timestamp:
10/22/2017 05:28:45 AM (2 years ago)
Author:
trac
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Yocto/Video_In

    v1 v1  
     1[[PageOutline]]
     2
     3= Goals =
     4The intended goal of this article is to provide the user with enough information so they can capture video from an on-board video input device.
     5
     6For information regarding Audio / Video breakout adapters for Ventana see:
     7 * [wiki:ventana/breakoutadapters Audio / Video breakout Adapters]
     8
     9[=#capture]
     10= Video Capture Drivers (on board) =
     11There Video capture API in Linux today is the [https://www.kernel.org/doc/Documentation/video4linux/v4l2-framework.txt video4linux (v4l)] API. Each video capture source is represented by a /dev/video<n> device with /dev/video0 being the first. For more information see the Gateworks [wiki:linux/v4l2 v4l2] wiki page. Note that this is low level and Gateworks recommends using Gstreamer as noted below.
     12
     13The i.MX6 Video capture framework drivers are currently only available in the Yocto BSP using the Freescale kernels. This driver framework has not made it into mainline linux yet and no support is available for the OpenWrt BSP.
     14
     15''' Please use our [wiki:Yocto/gstreamer GStreamer wiki page] for more information about video input via GStreamer'''
     16
     17
     18[=#devices]
     19= Video Input Sources (on board) =
     20Various Ventana boards have different video input possibilities:
     21 * GW51xx: CVBS/S-!Video/Component (Analog) (/dev/video0)
     22 * GW52xx: CVBS/S-!Video/Component (Analog) (/dev/video0)
     23 * GW53xx: CVBS/S-!Video/Component (Analog) (/dev/video0)
     24 * GW540x: HDMI (Digital) (/dev/video0), CVBS/S-!Video/Component (Analog) (/dev/video1)
     25 * GW551x: HDMI (Digital) (/dev/video0)
     26 * GW553x: CVBS/S-!Video/Component (Analog) (/dev/video0)
     27
     28
     29[=#cvbs]
     30== Analog Video Input ==
     31The GW5100/GW5200/GW5300/GW5400 all feature Analog Video CVBS (color, video, blanking, and sync).
     32
     33The Video input is provided via the [http://www.analog.com/static/imported-files/data_sheets/ADV7180.pdf ADV7180] Analog Video decoder chip.
     34
     35Notes:
     36 * CVBS refers to "Color, Video, Blanking, and Sync." - see http://en.wikipedia.org/wiki/Composite_video
     37 * CVBS modes supported: NTSC/PAL/SECAM
     38
     39
     40[=#cvbs-input]
     41=== Analog Video Input Source ===
     42The ADV7180 has 3 inputs (AIN1, AIN2, AIN3) which are all provided on the Ventana board Video Input connector. These can be used in the following combinations:
     43||= INSEL[3:0] =||= Video Format =||= Analog Input =||
     44|| 0000 (0)  || Composite         || CVBS input on AIN1 ||
     45|| 0011 (3)  || Composite         || CVBS input on AIN2 ||
     46|| 0100 (4)  || Composite         || CVBS input on AIN3 ||
     47|| 0110 (6)  || Y/C (S-Video)     || Y input on AIN1, C input on AIN2 ||
     48|| 1001 (9)  || YPrPb (Component) || Y input on AIN1, Pb input on AIN2, Pr input on AIN3 ||
     49 * to specify the input configuration set the INSEL[3:0] value above to Address 0x00[3:0] (bits 3-0)
     50 * the adv7180 i2c address is 0x20 on /dev/i2c-2
     51 * the default is 0 - Composite CVBS input on AIN1
     52
     53The adv7180 v4l2 driver does not support setting the input configuration via software, but its simple to do so manually.
     54
     55Example (referencing the table above):
     56  * Set adv7180 mode to 3 for analog input #2 (AIN2) using the INSEL variable:
     57   * Copy and paste the below code, setting the INSEL variable to whichever mode desired according to the table above.
     58{{{
     59INSEL=3
     60# set 0x00[3:0] (without disturbing the other bits)
     61r0=$(i2cget -f -y 2 0x20 0x00)  # get current value
     62r0=$((r0&0xf0)) # mask out lower nibble
     63r0=$((r0|$INSEL)) # set lower nibble
     64i2cset -f -y 2 0x20 0x00 $r0
     65}}}
     66
     67 * Set mode6 for S-Video using AIN1/AIN2 using the INSEL variable:
     68{{{
     69INSEL=6
     70# set 0x00[3:0] (without disturbing the other bits)
     71r0=$(i2cget -f -y 2 0x20 0x00)  # get current value
     72r0=$((r0&0xf0)) # mask out lower nibble
     73r0=$((r0|$INSEL)) # set lower nibble
     74i2cset -f -y 2 0x20 0x00 $r0
     75}}}
     76 * set mode9 for component video on AIN1/AIN2/AIN3:
     77{{{
     78INSEL=9
     79# set 0x00[3:0] (without disturbing the other bits)
     80r0=$(i2cget -f -y 2 0x20 0x00)  # get current value
     81r0=$((r0&0xf0)) # mask out lower nibble
     82r0=$((r0|$INSEL)) # set lower nibble
     83i2cset -f -y 2 0x20 0x00 $r0
     84}}}
     85
     86Note that the ADV7180 and IMX6 SoC can encode/capture only a single stream at a time, however you could round-robin the Composite AIN1/AIN2/AIN3 inputs if you want to essentially capture 3 streams at a time but you can not achieve a high framerate as you need to wait for the input to lock after each change.
     87
     88
     89[=#cvbs-format]
     90=== Analog Video Input Standard ===
     91The ADV7180 supports NTSC, PAL, and SECAM standards. You can use the Video4Linux API to determine if an input is detected and what mode by using the 'v4l2-ctl --get-standard' command which reports one of the following:
     92 * No supported input detected - Video Standard = 0x00ffffff
     93 * NTSC - Video Standard = 0x000000ff
     94 * PAL - Video Standard = 0x000000ff
     95
     96Example:
     97 * Show Analog Video status on GW51xx/GW52xx/GW53xx (/dev/video0):
     98{{{
     99v4l2-ctl -d /dev/video0 --get-standard
     100}}}
     101 * Show Analog Video status on GW54xx (/dev/video1)
     102{{{
     103v4l2-ctl -d /devivideo0 --get-standard
     104}}}
     105
     106
     107
     108[=#hdmi]
     109== HDMI Digital Video Input ==
     110The Ventana HDMI Digital Video input is provided via the [http://www.bdtic.com/NXP/TDA19971.html TDA19971] HDMI receiver chip.
     111
     112=== HDMI Input Examples ===
     113''' For examples on how to use HDMI video input on the board via GStreamer Software, visit the [wiki:Yocto/gstreamer GStreamer wiki page] for more information '''
     114
     115=== Hardware Capabilities and video data base mode ===
     116The TDA19971 has a 24bit video data bus that it can present data output in a variety of formats. The IMX6 Capture Sensor Interface (CSI) has a 20bit video data bus and can accept data in a variety of formats. There are however, only two formats that overlap and are thus compatible between the two:
     117 * '''yuv422smp''': YUV422 semi-planar - 16bit data bus clocked at 1x (1 clock per pixel) capturing 8bit per component YUV422 in a semi-planar arrangement using external sync signals
     118 * '''yuv422bt656''': YUV422 CCIR656 - 8bit data bus clocked at 1/2x (2 clocks per pixel) capturing 8bit per component YUV422 via BT656 protocol with embedded sync signals
     119
     120While the TDA19971 supports 8bit per component RGB444 and YUV444 formats, the IMX6 can not consume this data because it doesn't the required 24bit data bus available.
     121
     122The TDA19971 when used with the IMX6 will always output YUV data (doing a color-conversion on the TDA19971 for HDMI input sources that are RGB).
     123
     124There are trade-offs depending on the video data bus mode chosen between the TDA19971 and the IMX6 above:
     125 * '''yuv422smp''': can capture '''up to 1080p@60Hz''', but lacks interlaced video support (which is assumed to be a driver shortcomming at this time) and outputs UYVY which must use an IPU/GPU/PXP transform if needing to pass it to the encoder
     126 * '''yuv422bt656''': can capture '''up to 1080p@30Hz''' (as each pixel takes 2 clock cycles) but supports interlaced video and outputs YU12 which needs no transform if needing to pass it to the encoder
     127
     128To determine the video bus mode the driver is using look at the device-tree:
     129{{{#!bash
     130echo $(cat /proc/device-tree/soc/aips-bus@02100000/i2c@021a8000/tda1977x@48/vidout_fmt)
     131}}}
     132 * a value of '''422_smp''' indicates '''yuv422smp'''
     133 * a value of '''422_ccir''' indicates '''yuv422bt656'''
     134
     135
     136[=#hdmi-format]
     137==== Select Between {{{yuv422smp}}} and {{{yuv422bt656}}} ====
     138Currently, products with HDMI video input are defaulted to {{{yuv422smp}}} as this allows capturing at 1080p60, except for the GW551x-A revision board (Please see errata [http://trac.gateworks.com/wiki/ventana/errata#HW9GW551x-AYUV422semi-planarcapturenotsupporteddoesnotsupport1080p60Hz HW9]). However, this can be changed through a bootloader environmental variable {{{hdmiinfmt}}}.
     139
     140In order to default to yuv422smp every time, the following steps would occur:
     141 1. Breakout into the bootloader
     142 1. Type the following:
     143{{{
     144Ventana > setenv hdmiinfmt yuv422smp
     145Ventana > saveenv
     146}}}
     147 1. Boot
     148
     149In order to default to yuv422bt656 every time, the following steps would occur:
     150 1. Breakout into the bootloader
     151 1. Type the following:
     152{{{
     153Ventana > setenv hdmiinfmt yuv422bt656
     154Ventana > saveenv
     155}}}
     156 1. Boot
     157
     158
     159[=#tda177x]
     160=== tda1997x Linux driver ===
     161The tda1997x multi-function driver core monitors the chip for HDMI input signals and provides information about the input source via sysfs:
     162{{{
     163# ls /sys/bus/i2c/devices/2-0048/
     164audmode     edid        modalias    product     uevent
     165colorspace  edid-ascii  name        state       vendor
     166driver      info        power       subsystem   vidmode
     167}}}
     168
     169The following sysfs files are useful in determining info about the HDMI input source:
     170 * audmode - audio input
     171 * vidmode - video output mode (<width>x<height>@<framerate>Hz<i|p>)
     172 * colorspace - video input colorspace
     173 * state - initialized|configured|locked|unlocked (will be 'locked' when locked on a valid HDMI input source)
     174 * vendor - input device info
     175 * product - input device info
     176 * edid - read/write binary EDID presented to HDMI sources
     177
     178To determine the presence, and format of a detected HDMI input signal for example you could:
     179{{{
     180if [ "$(cat /sys/bus/i2c/devices/2-0048/state)" = "locked" ]; then
     181  cat /sys/bus/i2c/devices/2-0048/{vidmode,colorspace,audmode}
     182else
     183  echo "No signal"
     184fi
     185}}}
     186
     187
     188[=#hdmi-supported]
     189=== Supported resolutions and formats ===
     190Resolutions ranging from 1080p to 480i at various frequencies are supported:
     191 * see [https://github.com/Gateworks/linux-imx6/blob/gateworks_3.10.17_1.0.0_ga/drivers/mfd/tda1997x-core.c#L946 driver for details]
     192 * regardless of what modes the tda1997x driver supports, the [#edid EDID] is supposed to be honored by HDMI output sources when deciding upon formats.
     193
     194The following '''video input colorspaces''' and '''colorimetry''' formats are supported:
     195 * RGB444 '''(required by HDMI spec)'''
     196 * YUV444 ITU601/ITU709
     197 * YUV422 ITU601/ITU709
     198 * deep color (30/36bit) (untested)
     199 * XVYCC (untested)
     200
     201The following '''audio input configurations''' are supported:
     202 * 44.1/48/88.2/96/172.4/192kHz sample rates
     203 * 8 channels '''(although only 2 channels can be output to the IMX6)'''
     204 * HBR streams (compatible with DTS-HD master audio and Dolby TrueHD) (untested)
     205
     206Note that while RGB444/YUV444 colorspace is supported on the HDMI input, '''the TDA19971 will apply a colorspace conversion (using the specified colorimetry) or downsampling to convert to YUV422 to output to the IMX6 CSI'''. This is because RGB444/YUV444 require a 24bit data bus that the IMX6 CSI does not support.
     207
     208Note that while 8 channels of High Bit Rate (HBR) or L-PCM audio is supported on the HDMI input, '''the I2S (Inter-IC Sound) bus between the TDA19971 and the IMX6 supports one data signal allowing for 2-ch Linear PCM (IEC60958), Encoded Audio Bitstream (IEC61937), or High Bit Rate (HBR) Encoded Audio (IEC61937)'''.
     209
     210The '''deep color''' and '''xvYCC''' colorspace options added to HDMI v1.3 are supported by the TDA19971 and the driver but are currently untested. Deep color increases the available bit depth for each color component and xvYCC makes the overall color gamut larger. Neither of these modes should be useful when the TDA19971 is connected to an IMX6 CSI bus in YUV422 or YUV422-BT656 mode yet currently these are marked as supported in the default EDID.
     211
     212=== Tested resolutions and formats ===
     213While we have not had the equipment available to test all the combinations of the above formats, the following combinations of input formats have been tested:
     214||= Resolution / Framerate =||= AR =||= Colorspace =||= Audio =||= Device Tested =||= Notes =||
     215|| 640x480p@60Hz   || 4:3 || RGB || 2-ch 48/44.1kHz || Roku 2710X (Roku1) ||  ||
     216|| 1280x720p@60Hz  || 16:9 || RGB || 2-ch 48/44.1kHz || Roku 2710X (Roku1) ||  ||
     217|| 1280x720p@60Hz  || 16:9 || RGB || 2-ch 48/44.1kHz || Roku 2710X (Roku1) ||  ||
     218|| 1920x1080p@60Hz || 16:9 || RGB || 2-ch 48/44.1kHz || Roku 2710X (Roku1) || yuv422smp^1^ ||
     219|| 1280x720p@60Hz || 16:9 || RGB || 2-ch 48kHz || Dino-Lite Microscope ||  ||
     220|| 640x480p@60Hz  || 4:3 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD                ||  ||
     221|| 720x576p@50Hz PAL-2 || 5:4 ||  YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD  ||  ||
     222|| 720x480p@59Hz NTSC-3 || 3:2 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     223|| 720x480p@60Hz NTSC-4 || 3:2 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     224|| 1280x720p@24Hz || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     225|| 1280x720p@25Hz || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     226|| 1280x720p@29Hz || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     227|| 1280x720p@30Hz || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     228|| 1280x720p@50Hz || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     229|| 1280X720p@59Hz NTSC-5 || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     230|| 1280x720p@60Hz || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     231|| 1920x1080p@24Hz PAL-6 || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     232|| 1920x1080p@25Hz || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     233|| 1920x1080p@30Hz NTSC-8 || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD ||  ||
     234|| 1920x1080i@50Hz PAL-5 || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD || yuv422bt656^2^ ||
     235|| 1920x1080p@50Hz PAL-9 || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD || yuv422smp^1^ ||
     236|| 1920x1080i@59Hz || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD || yuv422bt656^2^ ||
     237|| 1920x1080i@60Hz NTSC-7 || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD || yuv422bt656^2^ ||
     238|| 1920x1080p@60Hz NTSC-9 || 16:9 || YUV444 ITU601 || 2-ch 48kHz || Hauppauge MediaMVP-HD || yuv422smp^1^ ||
     239 1. 1080p@60Hz requires yuv422smp video bus format
     240 2. interlaced video requires yuv422bt656 video bus format
     241
     242Notes:
     243 * the above was tested using Yocto v1.7 with the gateworks_3.10.17_1.0.0-ga-g4d177f6 kernel
     244
     245
     246[=#edid]
     247=== Extended display identification data (EDID) ===
     248Extended display identification data or '''EDID''' is a standard that defines a compact binary file format describing a digital display's capabilities and supported graphics mode. Because an HDMI input is an '''HDMI sink'''  it can be thought of as a display and must support EDID so that an '''HDMI source''' can choose a supported display format and resolution.
     249
     250The EDID is electrically accessed via the DDC channel over an HDMI cable. The DDC channels is an i2c channel and the EDID of an HDMI sink is powered by the HDMI source through a +5V signal on the HDMI connector capable of providing up to 50mA. This allows an HDMI source to query the EDID of an HDMI sink even if the HDMI sink is powered off. Typically the EDID is stored in a i2c based EEPROM device powered off this +5V signal from the HDMI source.
     251
     252The Ventana boards using the tda1997x HDMI receiver on the other hand, provide the EDID from the tda1997x itself. The EDID is programmed into the tda1997x's volatile memory from the tda1997x-core.c driver. If necessary, this driver allows the edid to be get/set by accessing the sysfs property /sys/bus/i2c/drivers/tda1997x/2-0048/edid as an alternate method to modifying the source code directly. For example:
     253 * Get EDID from HDMI Receiver:
     254{{{#!bash
     255hexdump -C /sys/bus/i2c/devices/2-0048/edid
     25600000000  00 ff ff ff ff ff ff 00  1e e3 00 50 01 00 00 00  |...........P....|
     25700000010  01 17 01 03 a2 00 00 00  02 ee 95 a3 54 4c 99 26  |............TL.&|
     25800000020  0f 50 54 20 00 00 01 01  01 01 01 01 01 01 01 01  |.PT ............|
     25900000030  01 01 01 01 01 01 02 3a  80 18 71 38 2d 40 58 2c  |.......:..q8-@X,|
     26000000040  45 00 c4 8e 21 00 00 1e  00 00 00 fc 00 47 57 20  |E...!........GW |
     26100000050  56 65 6e 74 61 6e 61 0a  20 20 00 00 00 fd 00 1e  |Ventana.  ......|
     26200000060  3c 0f 44 09 00 0a 20 20  20 20 20 20 00 00 00 fe  |<.D...      ....|
     26300000070  00 31 30 38 30 70 44 43  78 76 43 33 44 0a 01 89  |.1080pDCxvC3D...|
     26400000080  02 03 21 f0 4c 22 20 21  04 13 03 12 05 14 07 16  |..!.L" !........|
     26500000090  01 23 09 07 07 83 01 00  00 67 03 0c 00 00 00 b8  |.#.......g......|
     266000000a0  2d 01 1d 80 18 71 38 2d  40 58 2c 45 00 80 38 74  |-....q8-@X,E..8t|
     267000000b0  00 00 3f 01 1d 00 72 51  d0 1e 20 6e 50 55 00 00  |..?...rQ.. nPU..|
     268000000c0  d0 52 00 00 39 a0 0f 20  00 31 58 1c 20 28 80 14  |.R..9.. .1X. (..|
     269000000d0  00 20 58 32 00 00 3f d7  09 80 a0 20 e0 2d 10 08  |. X2..?.... .-..|
     270000000e0  60 22 01 80 e0 21 00 00  39 00 00 00 00 00 00 00  |`"...!..9.......|
     271000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 a7  |................|
     27200000100
     273}}}
     274 * Set updated EDID to HDMI Receiver:
     275{{{
     276cat edid  > /sys/bus/i2c/devices/2-0048/edid
     277[  377.266459] TDA1997x-core: New EDID being loaded
     278}}}
     279
     280
     281The EDID specification states that the timings should be preferred in the following order of priority:
     282 * preferred detailed mode
     283 * other detailed modes from base block
     284 * detailed modes from extension blocks
     285 * CVT 3-byte code modes
     286 * standard timing codes
     287 * established timing codes
     288 * modes inferred from GTF or CVT range information
     289
     290For Ventana's default EDID the above should translate to the following priority:
     291 * 1920x1080p@60Hz (Preferred Detailed mode Block 1)
     292 * 1920x1080p@30Hz (extension block Detailed Timing Block1)
     293 * 1280x720p@60Hz (extension block Detailed Timing Block2)
     294 * 800x600@60Hz (extension block Detailed Timing Block3)
     295 * 640x480@59Hz (extension block Detailed Timing Block4)
     296 * 1920x1080p@29Hz (SVD1)
     297 * 1920x1080p@24Hz (SVD2)
     298 * 1920x1080p@25Hz (SVD3)
     299 * 1280x720p@59Hz (SVD4)
     300 * 1280x720p@50Hz (SVD5)
     301 * 720x480p@59Hz (SVD6)
     302 * 720x576p@50Hz (SVD7)
     303 * 1920x1080i@59Hz (SVD8)
     304 * 1920x1080i@50Hz (SVD9)
     305 * 720x480i@59Hz (SVD10)
     306 * 720x576i@50Hz (SVD11)
     307 * 640x480p@60Hz (SVD12)
     308
     309Why would you want to edit the HDMI Receiver EDID?
     310 * use your product information (vendor ID, model string)
     311 * limit or extend the various modes advertised as supported for example:
     312  * limit to specific resolutions
     313  * limit to sRGB colorspace only (by clearing bits 4 and 4 in byte 3 of the CEA extension marking support for YUV444/YUV422)
     314  * remove deep-color support (by clearing bits 6-3 in VSD byte 6)
     315
     316You can use a variety of tools to view/edit the EDID information. Some examples we have used:
     317 * [http://www.deltacast.tv/products/software-applications/deltacast-e-edid-editor-dvi-hdmi-oem-video-cards.aspx Deltacast E-EDID Editor] (Windows)
     318 * http://www.edidreader.com/ (Web - viewer only, paste the output of {{{hexdump -C edid | cut -c11-60)}}})
     319
     320References:
     321 * http://en.wikipedia.org/wiki/Extended_display_identification_data
     322
     323
     324[=#hdcp]
     325=== High-bandwidth Digital Content Protection (HDCP) ===
     326HDMI can use High-bandwidth Digital Content Protection (HDCP) to encrypt the signal if required by the source device as a form of digital copy protection. The system is meant to stop HDCP-encrypted content from being played on unauthorized devices or devices which have been modified to copy HDCP content. Before sending data, a transmitting device checks that the receiver is authorized to receive it and if so, the transmitter encrypts the data to prevent eavesdropping as it flows to the receiver.
     327
     328In order to make a device that can playback material protected by HDCP the manufacturer must obtain a license from Intel subsidiary Digital Content Protection LLC, pay an annual fee, and submit to various conditions for example:
     329 * it must 'frustrate attempts to defeat the content protection requirements"
     330 * it must not transmit high definition protected video to non-HDCP receivers
     331 * DVD-audio material can only be played at CD-audio quality
     332
     333The HDMI input receiver used on the GW5510/GW5400 Ventana boards is based upon the NXP TDA19971 chip. The standard version that Gateworks loads does not contain HDCP support however a pin-compatible version of the chip '''is''' available (TDA19971A) and if you require HDCP support you can contact sales@gateworks.com for more information. Note that using the HDCP enabled TDA19971 would mean that your end device must adhere to the stipulations required by HDCP. The HDCP enabled version includes a HDCP 1.4 engine with pre-programmed keys stored into an internal non-volatile memory to provide a highly secured solution which simplifies the manufacturing process. The HDCP enabled version also features repeater capability (requires software driver).
     334
     335For HDMI output, the Ventana boards use the NXP i.MX6's HDMI output port. The standard i.MX6 CPU loaded on Gateworks boards does not support HDCP however special parts are available from NXP to qualified vendors with HDCP revision 1.4 capability. The HDCP transmitter in the i.MX6 implements the three layers of the HDCP cipher, including LFSR and other functions required to generate the encryption key bytes that are then XORed with the data.
     336
     337You may encounter a blank or 'all black' video signal due to HDCP encrypted content in the following scenarios for example:
     338 * A Roku device user interface works fine, but as soon as you try to play encrypted content such as that from Google Play, Netflix, Amazon Video, the display goes black
     339 * A Google Chromecast apparently does not even display the user interface
     340
     341Devices called HDCP strippers can remove the HDCP information from the video signal and allow the video to be playable on non-HDCP-compliant displays.
     342
     343References:
     344 * http://en.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection
     345 * https://community.freescale.com/thread/351004 - NXP Community Thread