| | 1 | [[PageOutline]] |
| | 2 | |
| | 3 | = Goals = |
| | 4 | The 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 | |
| | 6 | For 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) = |
| | 11 | There 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 | |
| | 13 | The 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) = |
| | 20 | Various 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 == |
| | 31 | The GW5100/GW5200/GW5300/GW5400 all feature Analog Video CVBS (color, video, blanking, and sync). |
| | 32 | |
| | 33 | The Video input is provided via the [http://www.analog.com/static/imported-files/data_sheets/ADV7180.pdf ADV7180] Analog Video decoder chip. |
| | 34 | |
| | 35 | Notes: |
| | 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 === |
| | 42 | The 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 | |
| | 53 | The adv7180 v4l2 driver does not support setting the input configuration via software, but its simple to do so manually. |
| | 54 | |
| | 55 | Example (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 | {{{ |
| | 59 | INSEL=3 |
| | 60 | # set 0x00[3:0] (without disturbing the other bits) |
| | 61 | r0=$(i2cget -f -y 2 0x20 0x00) # get current value |
| | 62 | r0=$((r0&0xf0)) # mask out lower nibble |
| | 63 | r0=$((r0|$INSEL)) # set lower nibble |
| | 64 | i2cset -f -y 2 0x20 0x00 $r0 |
| | 65 | }}} |
| | 66 | |
| | 67 | * Set mode6 for S-Video using AIN1/AIN2 using the INSEL variable: |
| | 68 | {{{ |
| | 69 | INSEL=6 |
| | 70 | # set 0x00[3:0] (without disturbing the other bits) |
| | 71 | r0=$(i2cget -f -y 2 0x20 0x00) # get current value |
| | 72 | r0=$((r0&0xf0)) # mask out lower nibble |
| | 73 | r0=$((r0|$INSEL)) # set lower nibble |
| | 74 | i2cset -f -y 2 0x20 0x00 $r0 |
| | 75 | }}} |
| | 76 | * set mode9 for component video on AIN1/AIN2/AIN3: |
| | 77 | {{{ |
| | 78 | INSEL=9 |
| | 79 | # set 0x00[3:0] (without disturbing the other bits) |
| | 80 | r0=$(i2cget -f -y 2 0x20 0x00) # get current value |
| | 81 | r0=$((r0&0xf0)) # mask out lower nibble |
| | 82 | r0=$((r0|$INSEL)) # set lower nibble |
| | 83 | i2cset -f -y 2 0x20 0x00 $r0 |
| | 84 | }}} |
| | 85 | |
| | 86 | Note 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 === |
| | 91 | The 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 | |
| | 96 | Example: |
| | 97 | * Show Analog Video status on GW51xx/GW52xx/GW53xx (/dev/video0): |
| | 98 | {{{ |
| | 99 | v4l2-ctl -d /dev/video0 --get-standard |
| | 100 | }}} |
| | 101 | * Show Analog Video status on GW54xx (/dev/video1) |
| | 102 | {{{ |
| | 103 | v4l2-ctl -d /devivideo0 --get-standard |
| | 104 | }}} |
| | 105 | |
| | 106 | |
| | 107 | |
| | 108 | [=#hdmi] |
| | 109 | == HDMI Digital Video Input == |
| | 110 | The 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 === |
| | 116 | The 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 | |
| | 120 | While 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 | |
| | 122 | The 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 | |
| | 124 | There 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 | |
| | 128 | To determine the video bus mode the driver is using look at the device-tree: |
| | 129 | {{{#!bash |
| | 130 | echo $(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}}} ==== |
| | 138 | Currently, 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 | |
| | 140 | In order to default to yuv422smp every time, the following steps would occur: |
| | 141 | 1. Breakout into the bootloader |
| | 142 | 1. Type the following: |
| | 143 | {{{ |
| | 144 | Ventana > setenv hdmiinfmt yuv422smp |
| | 145 | Ventana > saveenv |
| | 146 | }}} |
| | 147 | 1. Boot |
| | 148 | |
| | 149 | In order to default to yuv422bt656 every time, the following steps would occur: |
| | 150 | 1. Breakout into the bootloader |
| | 151 | 1. Type the following: |
| | 152 | {{{ |
| | 153 | Ventana > setenv hdmiinfmt yuv422bt656 |
| | 154 | Ventana > saveenv |
| | 155 | }}} |
| | 156 | 1. Boot |
| | 157 | |
| | 158 | |
| | 159 | [=#tda177x] |
| | 160 | === tda1997x Linux driver === |
| | 161 | The 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/ |
| | 164 | audmode edid modalias product uevent |
| | 165 | colorspace edid-ascii name state vendor |
| | 166 | driver info power subsystem vidmode |
| | 167 | }}} |
| | 168 | |
| | 169 | The 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 | |
| | 178 | To determine the presence, and format of a detected HDMI input signal for example you could: |
| | 179 | {{{ |
| | 180 | if [ "$(cat /sys/bus/i2c/devices/2-0048/state)" = "locked" ]; then |
| | 181 | cat /sys/bus/i2c/devices/2-0048/{vidmode,colorspace,audmode} |
| | 182 | else |
| | 183 | echo "No signal" |
| | 184 | fi |
| | 185 | }}} |
| | 186 | |
| | 187 | |
| | 188 | [=#hdmi-supported] |
| | 189 | === Supported resolutions and formats === |
| | 190 | Resolutions 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 | |
| | 194 | The 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 | |
| | 201 | The 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 | |
| | 206 | Note 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 | |
| | 208 | Note 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 | |
| | 210 | The '''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 === |
| | 213 | While 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 | |
| | 242 | Notes: |
| | 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) === |
| | 248 | Extended 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 | |
| | 250 | The 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 | |
| | 252 | The 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 |
| | 255 | hexdump -C /sys/bus/i2c/devices/2-0048/edid |
| | 256 | 00000000 00 ff ff ff ff ff ff 00 1e e3 00 50 01 00 00 00 |...........P....| |
| | 257 | 00000010 01 17 01 03 a2 00 00 00 02 ee 95 a3 54 4c 99 26 |............TL.&| |
| | 258 | 00000020 0f 50 54 20 00 00 01 01 01 01 01 01 01 01 01 01 |.PT ............| |
| | 259 | 00000030 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c |.......:..q8-@X,| |
| | 260 | 00000040 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 47 57 20 |E...!........GW | |
| | 261 | 00000050 56 65 6e 74 61 6e 61 0a 20 20 00 00 00 fd 00 1e |Ventana. ......| |
| | 262 | 00000060 3c 0f 44 09 00 0a 20 20 20 20 20 20 00 00 00 fe |<.D... ....| |
| | 263 | 00000070 00 31 30 38 30 70 44 43 78 76 43 33 44 0a 01 89 |.1080pDCxvC3D...| |
| | 264 | 00000080 02 03 21 f0 4c 22 20 21 04 13 03 12 05 14 07 16 |..!.L" !........| |
| | 265 | 00000090 01 23 09 07 07 83 01 00 00 67 03 0c 00 00 00 b8 |.#.......g......| |
| | 266 | 000000a0 2d 01 1d 80 18 71 38 2d 40 58 2c 45 00 80 38 74 |-....q8-@X,E..8t| |
| | 267 | 000000b0 00 00 3f 01 1d 00 72 51 d0 1e 20 6e 50 55 00 00 |..?...rQ.. nPU..| |
| | 268 | 000000c0 d0 52 00 00 39 a0 0f 20 00 31 58 1c 20 28 80 14 |.R..9.. .1X. (..| |
| | 269 | 000000d0 00 20 58 32 00 00 3f d7 09 80 a0 20 e0 2d 10 08 |. X2..?.... .-..| |
| | 270 | 000000e0 60 22 01 80 e0 21 00 00 39 00 00 00 00 00 00 00 |`"...!..9.......| |
| | 271 | 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a7 |................| |
| | 272 | 00000100 |
| | 273 | }}} |
| | 274 | * Set updated EDID to HDMI Receiver: |
| | 275 | {{{ |
| | 276 | cat edid > /sys/bus/i2c/devices/2-0048/edid |
| | 277 | [ 377.266459] TDA1997x-core: New EDID being loaded |
| | 278 | }}} |
| | 279 | |
| | 280 | |
| | 281 | The 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 | |
| | 290 | For 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 | |
| | 309 | Why 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 | |
| | 316 | You 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 | |
| | 320 | References: |
| | 321 | * http://en.wikipedia.org/wiki/Extended_display_identification_data |
| | 322 | |
| | 323 | |
| | 324 | [=#hdcp] |
| | 325 | === High-bandwidth Digital Content Protection (HDCP) === |
| | 326 | HDMI 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 | |
| | 328 | In 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 | |
| | 333 | The 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 | |
| | 335 | For 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 | |
| | 337 | You 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 | |
| | 341 | Devices 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 | |
| | 343 | References: |
| | 344 | * http://en.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection |
| | 345 | * https://community.freescale.com/thread/351004 - NXP Community Thread |
