Tier 2, 3 IPTV deployment — What's the problem?
With all due respect to Manish Matta, director of marketing for UT-Starcom, I'm not sure he has the pulse on Tier 2 and 3 operators. (See “Lack of broadband critical mass, content aggregation plague Tier 2, 3 IPTV deployment” in the Jan. 22 edition of the “IPTV Update” e-newsletter.)
Matta points out the lack of broadband critical mass as a stumbling block, but he uses the term in a way that suggests he has confused the IPTV market with Internet TV. Many ITCs have built out ADSL2+ and BPON/GPON networks in both their urban and rural areas precisely for video, but they haven't been able to launch their video platform due to reasons other than what Matta describes. That said, Tier 2 and 3 operators know that their customer bases are small, so they try to leverage the hardware volumes of the Tier 1 vendors to drive down prices, and depend on consultants and cookie-cutter installations to keep startup and operational costs at a minimum.
Content is a challenge, but not an impossible one. Third parties have done much of the hard work in negotiating agreements. So what is the problem? Matta needs to point the finger at those who make the middleware and other hardware components. The woes of IPTV middleware vendors have not been well documented, but they've missed pretty well every self-imposed milestone, and many promises have been broken. The added complexity of the MPEG-4 ecosystem, at a time when these IPTV middleware vendors were just starting to sell, didn't do favors for anybody. I wouldn't call MPEG-2 a false start, but the resources the middleware vendors had to apply to MPEG-4 to get HD (not to speak of PVR functionality) meant that MPEG-2 software development crawled along.
The reality is that despite the hardware vendors' best intentions, MPEG-4 encoding and decoding is not as commoditized as they would make you to believe, and set-top box and middleware integration is an arduous affair. Toss conditional access (CA) into the mix, and it's a nightmare. Until groups come out with standards and vendors develop and ship products to that standard, the middleware/STB/CA integration challenges will remain the most significant stumbling block for North American Tier 2 and 3 operators.
Tech. and product dev. mgr.
Color space evolution
When the color space changed from SMPTE-C to ITU-709 for HD signals, the basic formula to compose the Y signal changed as well. The explanation came from the complex formula from which these values originate. These are derived from equations made from the D65 CIE x, y chromaticity coordinates and the chromaticity coordinates for the RGB primaries used for LCD monitors. (See SMPTE RP 177-1993). Because it is the same formula, with the same D65 reference point, the other parameters have changed. With a change of the RGB primary values, it would not be possible to exactly match a SMPTE-C CRT monitor with an LCD or anything else made for HD imaging. The saturated colors show small differences in tint and are a little more deep in color. Professionals and colorists will never be able to have something exactly similar to the CRT. Because of the change in primary colors, the intention was to open the limitation of the SMPTE-C color rendering. We need to stop using CRT as the reference and adopt the LCD monitor as the new reference. To continue product evolution, we have to change our minds and adopt the bigger range and the difference in some color rendition, accept these differences and use these new tools as the reference.
Le Groupe AFP
Aldo Cugnini responds:
Denis Armand makes some valid points about color space evolution, but the motivation for it was not LCD monitors. The change has to do with the problem of constant luminance, wherein the color difference signals contribute to the luminance signal and cause errors in the displayed brightness of high-frequency signals. This is due to the wrong order of gamma and matrix operations in the display (together with color-difference signal band-limiting), necessitated by the fact that the CRT performs the inverse gamma function. ITU-709 introduces a smaller error than CCIR-601, but it is still there. As LCD monitors require a different gamma correction, there is a potential for improving the situation, but this would require a hardware-intensive 3 × 3 matrix multiplication for each pixel, and most monitor manufacturers would rather leave this out.
Test Your Knowledge!
See the Freezeframe question of the month on page 6.