tru2way ri vendor meeting march 30, 2011 presenter: ri dev team location: cablelabs

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 RemarksSteve Reynolds, Senior VP Comcast

RI Review and Roadmap

Project Migration 1.1.4 Maintenance 1.1.5 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 https://ocap-ri.dev.java.net to http://java.net/projects/ocap-ri Migration to new project complete as of Jan 28, 2011

• Issue Tracker db has been migrated to Jira-based Issue Navigator db Located at http://java.net/jira/browse/OCAP_RI P1/P2 Issue Tracker priorities map to Blocker/Critical priorities in Issue Navigator

• The discussion forums are now located at http://www.java.net/forums/mobile-embedded/ocap-ri-users http://java.net/projects/ocap-ri/forums/porting-forum

• The wiki pages and SVN repository were unaffected by the migration https://community.cablelabs.com/wiki/display/OCORI/OCAP-RI+Public https://community.cablelabs.com/svn/OCAPRI

https://ocap-ri.dev.java.net/



http://java.net/projects/ocap-ri

http://java.net/jira/browse/OCAP_RI

http://www.java.net/forums/mobile-embedded/ocap-ri-users

http://java.net/projects/ocap-ri/forums/porting-forum



https://community.cablelabs.com/wiki/display/OCORI/OCAP-RI+Public

https://community.cablelabs.com/wiki/display/OCORI/OCAP-RI+Public

https://community.cablelabs.com/svn/OCAPRI

https://community.cablelabs.com/svn/OCAPRI

1.1.4 Maintenance• Maintenance is against RI only – Specifications are frozen

OCAP 1.1.3 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 1.1.4 Rel-F Release Notes Change Information

• Releases every 6 weeks 1.1.4 Rel-A – Released 06/03/10 1.1.4 Rel-B – Released 07/22/10 1.1.4 Rel-C – Released 09/09/10 1.1.4 Rel-D – Released 11/04/10 1.1.4 Rel-E – Released 12/16/10 1.1.4 Rel-F – Released 02/17/11 1.1.4 Rel-G – Scheduled for 03/31/11 - Draft Release Notes

https://community.cablelabs.com/svn/OCAPRI/trunk/release_notes/OCAP_RI_1.1.4_RC-F_ReleaseNotes.pdf

1.1.5 Bundle: RI + Spec + CTP

• 1.1.5 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 1.1.3 Core Spec was re-issued as 1.1.5 for consistency with Bundle labeling (no content changes from 1.1.3 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 1.1.5 - all changes roll forward into 1.2• Release Notes• Known 1.1.5 Interop Issues

1.2 Bundle: RI + Spec + CTP

• Scheduled for 4/14/11 • Includes all HN work carried forward from 1.1.5 release• Feature list includes

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/28 https://community.cablelabs.com/svn/OCAPRI/change_data/RI_I1_2_0_PA2/index.html https://community.cablelabs.com/svn/OCAPRI/change_data/RI_I1_2_0_PA3/index.html

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/

Transwrapping 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 1.1.12, 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 v4.0.2.4 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 Process • All code incorporated into the RI must follow the Coding 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 1.1.5• 3447 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. 2010. All Rights Reserved. Proprietary/Confidential. 04/10/2315

• Bundle 1.2 ECs force release of Host and OCAP specs to be in sync

o 3DTV• HOST2.1-CFR-N-10.1576-4 3D Host Requirements

• OCAP1.1.5-O-10.1630-2 3DTV Content Format Listener API

• OCAP1.1.5-O-10.1629-2 3DTV Alternative Content Event APIo SAS

• OCAP1.1.5-O-11.1643-2 Application Notification of CableCARD Reset

• CCIF2.0-R-11.1642-2 SAS CableCARD Reset

• OCAP & Host Specs point to outdated specs


OCAP 1.1.5

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 1.1.5 Specifications


OCAP 1.1.5

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


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


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


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-I11-110414, April 14, 2011, Cable Television Laboratories, Inc.

becomesCableCARD 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


[HOST] OpenCable Host Device 2.1 Core Functional Requirements, OC-SP-HOST2.1-CFR-I14-110414, April 14, 2011, Cable Television Laboratories, Inc.

[HOST-TC] OpenCable Host Thin Chassis Device Core Functional Requirements, OC-SP-HOSTTC-CFR-I05-110414, April 14, 2011, Cable Television Laboratories, Inc.

[OCAP] OpenCable Application Platform (OCAP) Profile 1.2, OC-SP-OCAP1.2-110414, April 14, 2011, Cable Television Laboratories, Inc.

[CCIF] CableCARD Interface 2.0 Specification, OC-SP-CCIF2.0-I23-110414, April 14, 2011, Cable Television Laboratories, Inc.

[CCCP] CableCARD Copy Protection 2.0 Specification, OC-SP-CCCP2.0-I11-110414, April 14, 2011, Cable Television Laboratories, Inc.

[CDL] Common Download 2.0, OC-SP-CDL2.0-I12-110414, April 14, 2011, Cable Television Laboratories, Inc.

[HOST-MFAT]

.

.

.

Host 2.0 Multi-FAT Receiver Extension, OC-SP-HOST2-MFATEXT-I02-110414, April 14, 2011, Cable Television Laboratories, Inc.

.

.

.

2.1 Normative ReferenceIn 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


OpenCable Matrix 1.1.4 1.1.5 1.2BUNDLE 1.2

HOST I14HOST-TC I05

OCAP 1.1.3 1.1.5 1.2CCIF I23CCCP I11CDL I12HOST-MFAT I02OC-SEC I08HOST-MIB I12HOST-DVR I03OCAP-DVR I06 I06 I07HOST-HN I05HNP I03 I04 I05HN-MIB I04OCAP-HN I05 I06 I07HN-SEC I01 I01 I02OCAP-FP I04 I04 I05OCAP-DS I03 I03 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 relationshipso Invoking an action

• Servero Object relationshipso Building a server


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


High Level Design


Client (Control Point)

Local or RemoteDevices

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)


Client Object Relationships


Invoking an Action• UPnPService.postActionInvocation(UPnPActionInvocation action,

UPnPActionResponseHandler handler,

Object info)


Server Object Relationships


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


State Variables (Client Side)


State Variables (Server Side)


Packet Inspection/Processing


UPnP “Diagnostics” EC Implementation –Wes Munsil

• Approach• Development Methodology• Timetable• What’s Been Hard• What’s Ahead• Conclusions


Approach

• Exploit existing investment in CyberLink for Java (http://www.cybergarage.org/twiki/bin/view/Main/CyberLinkForJava)

• Build on top of CyberLink• Continue CyberLink patch policy: patch only when and

as necessary• Consider UPnP Diagnostics API to be the new de facto

“UPnP porting layer”• Re-implement OCAP HN in terms of UPnP Diagnostics


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


Timetable


Sprint Dates User Stories Priorities

10 Feb 2-15 Initial RI design work and CTP test impl. (MAT 20)

7, 8

11 Feb 16-Mar 1 Impl. of common and client packages, with supporting CTP tests

4, 5

12 Mar 2-15 Continue impl. of common and client packages, add server package

2, 3

13 Mar 16-29 Continue impl. of common, client, and server packages

2, 3

14 Mar 30-Apr 12 Prepare for 1.2 release CTP code freeze 3/31

RI code freeze 4/7

EC v7availableFeb 15

What’s 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!


What’s Been Hard—Client/Server Separation

• UPnP Diagnostics has a clear, strong separation• CyberLink’s 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


What’s Been Hard—Device Identity

• CyberLink creates Device objects “left and right”• Ask for a Device’s parent twice, you’ll 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


What’s Been Hard—Message 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


Setting Handler


CyberLink

MessageInterceptor

app object

UPnPControlPoint

UPnPInputInterceptor

1: setIncomingMessageHandler(inHandler)

2: new(inHandler)

3: interceptor

4: setClientInputInterceptor(interceptor)

UPnPIncomingMessageHandler

Interceptor

Operation of Handler


CyberLink

MessageInterceptorUPnPInputInterceptor

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)

What’s Been Hard—Debugging 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!


What’s 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


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 Allman’s talk

• Arguably the most well-designed and well-tested code in the RI


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 stream’s 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 doesn’t 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 1 - 5 generate S3DSignalingChangedEvents and recover from 3D alternative content if needed

• Options 6 - 8 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-11.1643-1(Application Notification of CableCARD Reset) to be part of OCAP 1.2 specification

• Corresponding CCIF EC CCIF2.0-R-11.1642-1 (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 STB’s 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


• 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


• 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 group’s

RR interval• No RR performed if there’s only a single filter at highest

priority in group• Groups could potentially have other applications


• 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 tha

t’s different than the TDM interval


• 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 tuner’s 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)


• 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 tuner’s first Filter Group• Initial PMT acquisition class and PMT revision class are

assigned the tuner’s second Filter Group• Secondary PMT acquisition class is unassigned (non-selected

PMT acquisition is not performed)• Will use 2t filters• No TDM (filters don’t 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)


• 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 don’t require changing acquisition logic – just Filter

Class/Filter Group associations


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 1.1.4

o 19 FAIL or UNRESOLVEDo 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 1.1.4

o 52 Failo 103 Passo 14 Warningso 95 NAo 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 changes• Version Control System• Defect Tracking• Comcast SNMP contribution – Porting Guide

tru2way ri vendor meeting march 30, 2011 presenter: ri dev team location: cablelabs

Documents

cablelabs slide

ri phasing

ri work sdvspi ri maintenance

hn work

hn interop

pa3in slide

comsvnocapri slide

ocap core