Tru2way RI Vendor Meeting March 30, 2011 Presenter: RI Dev Team Location: CableLabs

Agenda Introductory Remarks - Steve Reynolds RI Review and Roadmap – CableLabs Team Discussion Topics – CableLabs and Vendor Teams

Introductory Remarks Steve Reynolds, Senior VP Comcast

RI Review and Roadmap Project Migration Maintenance Bundle 1.2 Bundle 1.3 Early Feature List MSO Guide Testing Open Source Contributions CTP Test Process OpenCable Specification Reference Reconciliation

Project Migration – Dave Hooley Oracle/Sun has migrated the OCAP-RI open source project host site From to Migration to new project complete as of Jan 28, 2011 Issue Tracker db has been migrated to Jira-based Issue Navigator db Located at P1/P2 Issue Tracker priorities map to Blocker/Critical priorities in Issue Navigator The discussion forums are now located at The wiki pages and SVN repository were unaffected by the migration

1.1.4 Maintenance Maintenance is against RI only – Specifications are frozen OCAP core specification DVR I06 extension Front Panel I04 extension Device Settings I03 extension Home Networking I05 extension HN Protocol I03 Done in separate svn branch See Section 1 of the Rel-F Release NotesRelease Notes Change Information Releases every 6 weeks Rel-A – Released 06/03/ Rel-B – Released 07/22/ Rel-C – Released 09/09/ Rel-D – Released 11/04/ Rel-E – Released 12/16/ Rel-F – Released 02/17/ Rel-G – Scheduled for 03/31/11 - Draft Release Notes

1.1.5 Bundle: RI + Spec + CTP Rel-A RI released 2/24/11 Target for HN interop 3/28-4/1 Spec changes confined to the Home Networking extension only The Core Spec was re-issued as for consistency with Bundle labeling (no content changes from to 1.1.5) 22 HN-EXT and HNP ECRs included Many bug fixes, including 8 P1 Issue Tracker HN issues Included HN Track Changes RI backlog item No maintenance planned for all changes roll forward into 1.2 Release Notes Known Interop Issues

1.2 Bundle: RI + Spec + CTP Scheduled for 4/14/11 Includes all HN work carried forward from release Feature list includesFeature list Storage limited DVR Profile 3DTV Phase 1 Application Notification of Cablecard Reset UPnP Diagnostics Other RI work SDV/SPI RI maintenance Early 1.2 code drops on 1/31 and 2/

Early list of potential 1.3 features [ Please note that 1.3 has not been scheduled] HN 3.0 Streaming of Live Content to DLNA Devices Application Presentation Control OCAP 1543: Update focus handling rules and hscene management APIs OCAP 1539: HScene Blending for WBA IPv6 support USB Flash Drive Remote Diagnostics ETV Time Shifted Support for DVR, including over HN Platform Performance Metrics DVR: Default Recording Volume Determination 3DTV phase 2 OCAP: Boot Process Enhancement for Diagnostics HDMI CEC (Consumer Electronics Control) Front Scene Changed Event HNP: Multiple HN Interfaces HN IP Stack Isolation Transcoding/Transrating/Transcryption/Tr answrapping HN 3.0 content Clarify requirements for HTTPS support Detect Insufficient App Storage Space HTML5 extension (optional extension) Additional OCAP RemoteControl Key Event Codes Simplification of T2W / java security model

MSO Guide Testing Comcast Guide Testing Buckeye/Barcelona , CMAC v1.64 now running at CL Daily Buckeye smoke testing on the RI Phasing out Aspen testing in favor of Buckeye testing TWC ODN Guide Testing ODN v now running at CL Work in progress to bring up ODN VOD server at CL Daily ODN smoke testing on the RI, including HN tests Cox Trio Guide Testing Trio CMAC v12.6 engineering build now running at CL Daily Trio smoke testing on the RI

Open Source Contributions Contributions must follow the Contribution ProcessContribution Process All code incorporated into the RI must follow the Coding GuidelinesCoding Guidelines Palamida open source scanning tool is applied to all contributions Major contributions accepted to date TVT contribution from TVWorks (SDK) CA_PMT contribution from EchoStar MMI contribution from EchoStar Currently under evaluation MMI refactor from Comcast SNMP/Diagnostics from Comcast PAT/PMT processing from Comcast CANH from Cox (SDK) Have incorporated numerous minor contributions in the form of bug fixes

CTP Testing – Kevin Kershaw CTP Tests are Black-Box unit tests More than 5500 CTP tests in all – for Bundle in MHP & HAVi core spec areas 1197 in OCAP Core 877 in OCAP Extensions CTP is built w/ new tests weekly; regression run against RI About 1% failure rate for CTP tests run on RI Recent Platform testing All MSO Sponsored – no recent retail certifications Videotron & Comcast – select platforms Test Information Tools CTP Test Description Package Test Link Coverage Database Vendor / MSO Request – looking for ways to get CTP contributions along with source code contributions

CTP Test Description Package

Test Link Coverage Database

OpenCable Specification Reference Reconciliation - Mark Dulapa Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ Bundle 1.2 ECs force release of Host and OCAP specs to be in sync o 3DTV HOST2.1-CFR-N D Host Requirements OCAP1.1.5-O DTV Content Format Listener API OCAP1.1.5-O DTV Alternative Content Event API o SAS OCAP1.1.5-O Application Notification of CableCARD Reset CCIF2.0-R SAS CableCARD Reset OCAP & Host Specs point to outdated specs

Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ OCAP OCAP-DVR I06 HNP I04 OCAP-HN I06 HN-SEC I01 OCAP-FP I04 OCAP-DS I03 HOST-HN I04 HN-MIB I03 HOST I13 HOST-TC I04 CCIF I22 CCCP I10 CDL I11 HOST-MFAT I01 OC-SEC I07 HOST-MIB I11 HOST-DVR I02 Current Specifications

Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ OCAP OCAP-DVR I06 HNP I04 OCAP-HN I06 HN-SEC I01 OCAP-FP I04 OCAP-DS I03 HOST-HN I04 HN-MIB I03 HOST I13 HOST-TC I04 CCIF I22 CCCP I10 CDL I11 HOST-MFAT I01 OC-SEC I07 HOST-MIB I11 HOST-DVR I02 38 Correct OpenCable References

Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ OCAP 1.1.5, 1.1.3, 1.1.2, I15, I16 OCAP-DVR I06, I05 HNP I04, I02 OCAP-HN I06, I04 HN-SEC I01 OCAP-FP I04 OCAP-DS I03 HOST-HN I04 HN-MIB I03, I02 HOST I13, I11, I12, I09, I04, I10 HOST-TC I04 CCIF I22, I19, I21, I01, I08 CCCP I10, I01, I04 CDL I11 HOST-MFAT I01 OC-SEC I07 HOST-MIB I11 HOST-DVR I02, I01 36 Incorrect OpenCable References

Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ OCAP 1.1.5, 1.1.3, 1.1.2, I15, I16 OCAP-DVR I06, I05 HNP I04, I02 OCAP-HN I06, I04 HN-SEC I01 OCAP-FP I04 OCAP-DS I03 HOST-HN I04 HN-MIB I03, I02 HOST I13, I11, I12, I09, I04, I10 HOST-TC I04 CCIF I22, I19, I21, I01, I08 CCCP I10, I01, I04 CDL I11 HOST-MFAT I01 OC-SEC I07 HOST-MIB I11 HOST-DVR I02, I01 All OpenCable References

Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ Bundle Spec References to OpenCable specification in the 18 bundle specs become floating references e.g. CableCARD Copy Protection 2.0 Specification, OC-SP- CCCP2.0-I , April 14, 2011, Cable Television Laboratories, Inc. becomes CableCARD Copy Protection 2.0 Specification, OC-SP- CCCP2.0, Cable Television Laboratories, Inc. Referenced in [OC-BUNDLE]. The Bundle Specification contains exact release versions for the specifications included in the bundle A new Bundle Spec will be released when New OCAP specs are published, or New Host specs are published A Bundle Matrix will be posted on the OpenCable website

Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ [HOST] OpenCable Host Device 2.1 Core Functional Requirements, OC-SP-HOST2.1-CFR-I , April 14, 2011, Cable Television Laboratories, Inc. [HOST-TC]OpenCable Host Thin Chassis Device Core Functional Requirements, OC-SP-HOSTTC- CFR-I , April 14, 2011, Cable Television Laboratories, Inc. [OCAP]OpenCable Application Platform (OCAP) Profile 1.2, OC-SP-OCAP , April 14, 2011, Cable Television Laboratories, Inc. [CCIF]CableCARD Interface 2.0 Specification, OC-SP-CCIF2.0-I , April 14, 2011, Cable Television Laboratories, Inc. [CCCP]CableCARD Copy Protection 2.0 Specification, OC-SP-CCCP2.0-I , April 14, 2011, Cable Television Laboratories, Inc. [CDL]Common Download 2.0, OC-SP-CDL2.0-I , April 14, 2011, Cable Television Laboratories, Inc. [HOST-MFAT]. Host 2.0 Multi-FAT Receiver Extension, OC-SP-HOST2-MFATEXT-I , April 14, 2011, Cable Television Laboratories, Inc Normative Reference In order to claim compliance with this specification, it is necessary to conform to the following standards and other works as indicated, in addition to the other requirements of this specification. Notwithstanding, intellectual property rights may be required to use or implement such normative references. Sample of 1.2 Bundle Specification

Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ OpenCable Matrix BUNDLE 1.2 HOST I14 HOST-TC I05 OCAP CCIF I23 CCCP I11 CDL I12 HOST-MFAT I02 OC-SEC I08 HOST-MIB I12 HOST-DVR I03 OCAP-DVRI06 I07 HOST-HN I05 HNPI03I04I05 HN-MIB I04 OCAP-HNI05I06I07 HN-SECI01 I02 OCAP-FPI04 I05 OCAP-DSI03 I04 Bundle Matrix to be published on CL web site

CableLabs Discussion Topics Bundle 1.2 Features UPnP Diagnostics – Steve Glennon/Wes Munsil OpenGL ES – Jon Courtney/Greg Rutz 3DTV – Scott Deboy CableCard Reset – Prasanna Modem RI PSI Change Preview – Craig Pratt Vendor feedback on early 1.2 code drops UPnP and DLNA Testing – Scott Allman Eager vs lazy class loading – Jon Courtney/Greg Rutz

UPnP Diagnostics EC Introduction Steve Glennon 10/18/10

Summary Overview/Requirements High Level Design Client o Object relationships o Invoking an action Server o Object relationships o Building a server Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Overview/Requirements Ability to build and/or control any UPnP device Ability to get description (text) of any device o Logging Ability to modify packets on the wire o Windows media server example Ability to extend devices created by other apps Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

High Level Design Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ Client (Control Point) Local or Remote Devices Server Local Devices Only Common

Design Goals Provide everything UPnP (1.0) can do Cleanly separate client and server components Cleanly support multi-homed servers and control points Provide accessors for all (Device Arch. 1.0) fields Provide direct XML document access (read-only) o Allows discovery of non-standard elements Provide last ditch direct packet access (read/write) Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Client Object Relationships Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Invoking an Action UPnPService.postActionInvocation(UPnPActionInvocation action, UPnPActionResponseHandler handler, Object info) Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Server Object Relationships Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Building a Server srvcs[0] = DeviceManager.createService(type, description, actionServer, info); mgdDevice = DeviceManager.createDevice(null, description, srvcs); Alternately, createDevice with empty array, call mgdDevice.addService(); mgdDevice.sendByeBye(); mgdDevice.sendAlive(); actionServer will be invoked when control point posts an UPnP action Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

State Variables (Client Side) Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

State Variables (Server Side) Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Packet Inspection/Processing Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

UPnP Diagnostics EC Implementation – Wes Munsil Approach Development Methodology Timetable Whats Been Hard Whats Ahead Conclusions Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Approach Exploit existing investment in CyberLink for Java ( ) Build on top of CyberLink Continue CyberLink patch policy: patch only when and as necessary Consider UPnP Diagnostics API to be the new de factoUPnP porting layer Re-implement OCAP HN in terms of UPnP Diagnostics Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Development Methodology Scrum Small team, short iterations (two-week sprints) 3.5 RI developers, 2 CTP developers, 1 UPnP simulator developer Chickens from RI/CTP/Spec management Limited but increasing degree of staff fungibility Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Timetable Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ SprintDatesUser StoriesPriorities 10Feb 2-15 Initial RI design work and CTP test impl. (MAT 20) 7, 8 11Feb 16-Mar 1 Impl. of common and client packages, with supporting CTP tests 4, 5 12Mar 2-15 Continue impl. of common and client packages, add server package 2, 3 13Mar Continue impl. of common, client, and server packages 2, 3 14Mar 30-Apr 12 Prepare for 1.2 releaseCTP code freeze 3/31 RI code freeze 4/7 EC v7 available Feb 15

Whats Been Hard Adapting the CyberLink paradigm to the UPnP Diagnostics paradigm Poor client/server separation No concept of device identity Decentralized message handling code Debugging the EC… … but this is one of the most important parts of this effort! Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Whats Been HardClient/Server Separation UPnP Diagnostics has a clear, strong separation CyberLinks separation is spotty at best Examples: Much message handling code is shared between client and server A single Device class is used for both. Etc. Required: Some CyberLink patches CyberLink threading and path analysis Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Whats Been HardDevice Identity CyberLink creates Device objects left and right Ask for a Devices parent twice, youll get two different objects We felt this was not sufficient for UPnPDevice Required: Some CyberLink patches Grafting our own notion of device identity on top of CyberLink Device objects Maintaining our own map of Device ID Device Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Whats Been HardMessage Handling UPnP Diagnostics features a single point of message interception OK, 4 points: client/server x incoming/outgoing CyberLink has I/O all over the place Required: Patching CyberLink to allow generalized message interception Registering UPnPControlPoint and UPnPDeviceManager as CyberLink message interceptors Interceptor adaptation Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Setting Handler Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ CyberLink MessageInterceptor app object UPnPControlPoint UPnPInputInterceptor 1: setIncomingMessageHandler(inHandler) 2: new(inHandler) 3: interceptor 4: setClientInputInterceptor(interceptor) UPnPIncomingMessageHandler Interceptor

Operation of Handler Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/ CyberLink MessageInterceptor UPnPInputInterceptor UPnPIncomingMessageHandler Interceptor object 1: getInputInterceptor() 2: interceptor 3: intercept(host, port, message) 4: handleIncomingMessage(host/port, message.toByteArray(), DEFAULT_IMH) 5: upnpMessage 6: toMessage(upnpMessage)

Whats Been HardDebugging the EC So far the team has logged 25 spec issues, ranging from clarification issues to very substantial issues This has led to many spec clarifications, spec corrections, and other improvements We began with v7 of the EC Based on this work, the EC is now at v11 Some of the 25 issues remain; others may be raised This provides critical value! Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Whats Ahead Incorporate the v11 (v-x?) EC changes into the RI and CTP tests Some changes easy, some… uh… not Re-implement the RI in terms of the UPnP Diagnostics API Media Server, Content Directory Service, etc. This will represent the first real user of the API, and a compelling proof of concept More EC issues may arise Schedule for these activities is TBD Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

Conclusions Huge amount of pre-tested code, made available to platform vendors for free Traditional meaningless LOC metrics: RI: 9,900 RI unit tests: 1,600 CTP: 28,300 (248 tests at MAT 35) Some work done against UPnP/DLNA cert tests See Scott Allmans talk Arguably the most well-designed and well-tested code in the RI Cable Television Laboratories, Inc All Rights Reserved. Proprietary/Confidential. 1/3/

OpenGL ES – Jon Courtney & Greg Rutz

EC 1588 – OpenGL ES Incorporates JSR 239 (Java Bindings for OpenGL ES 1.x) as optional OCAP extension Approved by MSOs to remain at ECO status while vendors evaluate completeness of design No implementation planned for RI PC Platform Only minimal vendor feedback as of yet

OpenGL ES – Implementation challenges Multiple, overlapping, blended application windows Interaction between OpenGL an AWT May require new spec language to limit how/when application OpenGL calls may be allowed E.g., with regard to active rendering using OpenGL ES

OCAP 1.2 feature to provide application visibility into the presenting 3D video format and display incompatibilities EC-1629: Alternative Content Event API Transition to and recover from alternative content due to 3D conditions Signaled via S3DAlternativeContentErrorEvent EC-1630: 3DTV Content Format API Allow applications to query the current 3D configuration and be notified of 3D configuration changes org.ocap.media.VideoFormatControl, S3DConfiguration and S3DSignalingChangedEvent MPEOS API changes required 3D Video Support – Scott Deboy

S3DAlternativeContentErrorEvent Triggers 3D video not supported by the HDMI display device 3D format not supported by the 3D-capable HDMI display device No display device connected to an HDMI port If reason is FORMAT_NOT_SUPPORTED, video or black may be displayed (host device configuration) Recovery/transition to NormalContent may occur when the streams video format is supported by the display device

VideoFormatControl Accessor for S3DConfiguration, returns null if presenting 2D VideoFormatListener added to the control will receive S3DSignalingChangedEvents when the stream format changes

MPEOS API changes Events sent to the queue associated with decode/playback session: MPE_CONTENT_PRESENTING: The video format is being displayed or compatibility cannot be determined (e.g. display doesnt support automatic 3D switch and requires user interaction) Reasons: 2D or 3D success, 3D format unconfirmed MPE_CONTENT_NOT_PRESENTING: The video is not being displayed Reasons: data starvation, display device not 3D- capable, no HDMI-connected display device

MPEOS API changes continued MPE_3D_FORMAT_CHANGED Format has changed: 2D to 3D, 3D to 2D or 3D to 3D format change mpeos_*Get3DConfig (media, dvr, hn) returns the current 3D configuration Payload types and 3D formats defined Ports need to enqueue both an MPE_CONTENT_PRESENTING/NOT_PRESENTING as well as an MPE_3D_FORMAT_CHANGED event if a format change results in recovery or inability to present the content

Testing 3D video support on the RI Test via telnet interface (port 23000) Navigate to the appropriate menu based on the current presentation (TSB, Media broadcast, recording, hn) Options generate S3DSignalingChangedEvents and recover from 3D alternative content if needed Options generate 3D alternative content events with different reasons Option 6 does not block the display, 7 and 8 block the display On the RI, only Media/broadcast is blocked with options 7 – 8 Can also test data starvation and recovery (AlternativeContentErrorEvent - CONTENT_NOT_FOUND)

CableCARD Reset – Prasanna Modem New EC OCAP1.1.3-R (Application Notification of CableCARD Reset) to be part of OCAP 1.2 specification Corresponding CCIF EC CCIF2.0-R (SAS CableCARD Reset)

CableCARD Reset CableCARD reset may happen for many reasons Host may respond to a reset by rebooting When reset without a reboot applications will lose communication (SAS sessions) Other CableCARD activities affected by reset include CA sessions, XAIT/EAS monitoring etc.

CableCARD Reset EC proposes a solution to allow applications to restore communication with CableCARD after reset Registered applications will receive new SystemEvents CABLECARD_RESET_BEGIN and CABLECARD_RESET_COMPLETE When reset begins applications can shutdown open sessions Restore communication when reset is complete

CableCARD Reset In addition to SAS, implementation-managed CableCARD activities such as XAIT/EAS monitoring, SCTE-65 table monitoring, and CA sessions also need to be suspended/restored before/after the reset Interruption of CA sessions has secondary effects: alternative content presentation for broadcast presentations, DVR recording interruption, and time-shift buffering interruption

The RI currently has a PSI (PAT/PMT) acquisition system designed to use a single section filter Good: Low resource use. Leaves maximum section filters available for DSMCC object carousels/data carousels and OCAP applications. Good: Works well for initial PAT/PMT acquisition when 1 tuner is tuned at a time Bad: Potential latency in initial acquisition when more than one tuner is tuned simultaneously. Bad: Potentially high latency for detecting section revisions (PAT/PMT version changes) Bad: High switching costs for MPEOS implementations with high section filter setup overhead RI PSI Change Preview – Craig Pratt

Solution: Configurable acquisition modes and TDM delegation Allows the acquisition mode to be tailored to the STBs capabilities and resources Simplifies the acquisition state logic by separating SI logic from filter sharing logic Add modes which allow for dedicated per-tuner filters, role-based filters (e.g. filters dedicated to initial acquisition, filters dedicated to PSI revisioning), and hybrids Allow for acquisition timeout value to be separate from filter sharing time-division multiplex (round-robin) interval Retain the 1-filter mode as a low-resource/legacy acquisition mode RI PSI Change Preview

Current SITP

RI PSI Change Preview Updated SITP/Section Filter Manager

SITP will use 6 different filter classes Initial PAT Initial selected PMT Initial secondary PMT(s) Revision PAT Revision selected PMT Revision secondary PMT(s) Classes are assigned filter groups at startup for each (fixed) tuner Filter groups created by SITP at startup according to the selected mode SITP acquisition logic then works in terms of classes and filter priorities without concern for class-to-group associations RI PSI Change Preview

MPE Section Filter Manager Filter Groups Each group has a TDM (round robin) interval Filters can be added/removed from groups Each filter has the same attributes as a MPE section filter but adds timeout and priority attributes Only highest priority filters in group are serviced (allows for preemption) Each filter can have a timeout separate from the groups RR interval No RR performed if theres only a single filter at highest priority in group Groups could potentially have other applications RI PSI Change Preview

Mode 1: Legacy single-filter sharing SITP sets up a single Filter Group and all filter classes on all tuner state machines are assigned to this group Initial PAT/PMT acquisition is given high priority, everything else is given low priority This mode uses 1 filter - completely mimicking how the RI operates today and how it utilizes the MPEOS filter API Has the same pros/cons as the current RI acquisition model Does add the ability to use a acquisition timeout value thats different than the TDM interval RI PSI Change Preview

Mode 2: Dedicated filter per tuner SITP sets up a Filter Group for each tuner The filter classes on the associated tuner state machine is assigned to the tuners associated Filter Group Initial PAT/PMT acquisition is given high priority, everything else is given low priority Will use t filters (where t is the number of tuners) Eliminates PSI acquisition latency issues when multiple tuners are tuned simultaneously Reduces revision detection latency (PAT/PMT revisions are detected more rapidly) RI PSI Change Preview

Mode 3: Dedicated 2 filters per tuner without secondary acquisition SITP sets up 2 Filter Groups for each tuner Initial PAT acquisition class and PAT revision class are assigned the tuners first Filter Group Initial PMT acquisition class and PMT revision class are assigned the tuners second Filter Group Secondary PMT acquisition class is unassigned (non-selected PMT acquisition is not performed) Will use 2t filters No TDM (filters dont periodically cancel as they do today) No latency when multiple tuners are tuned simultaneously No revision detection latency PSI is not pre-acquired for non-selected channels (con) RI PSI Change Preview

Additional modes easily added Mode 4: Dedicated per-filter tuner for PAT and selected PMT with wandering PSI pre-fetch filter that scans non-selected PSI on all other tuners Mode 5: Mode 3 plus wandering PSI pre-fetch filter Mode $: Dedicated filters for all acquisition (for a box with unbounded filtering resources) Modes dont require changing acquisition logic – just Filter Class/Filter Group associations RI PSI Change Preview

Vendor feedback on early 1.2 code drops

UPnP and DLNA Testing – Scott Allman

UPnP CTT v 2.0 Question – Who here runs these tests? Running Release o 19 FAIL or UNRESOLVED o 91 Total Tests Waiting for an update to the upnp ctt tool – we have fixed everything we feel needs fixing.

DLNA CTT v 1.5 Question – Who here runs these tests? Running Release o 52 Fail o 103 Pass o 14 Warnings o 95 NA o 264 TOTAL RI fails many because of missing streaming functionality

Eager vs lazy class loading – Jon Courtney/Greg Rutz

Classloading differences between VMs Building the RI for HomeNetwork client devices HN classes are present, DVR classes are not present Currently the MSO guides do not run on the RI (PC Platform) when DVR classes are not present Guides run on STBs Have not been able to reproduce any classloading errors in test situations

Vendor Discussion Topics Upcoming MPEOS API changesMPEOS API changes Version Control System Defect Tracking Comcast SNMP contribution – Porting Guide