Skip to main content

Support for Encrypted Channel Decoding

9 replies [Last post]
amirn
Offline
Joined: 2009-05-06
Points: 0

Hi,

The RI 1.1.3 release does not appear to have support for encrypted channel decoding.
In particular there is no API support to get the *full* PMT from MPE or MPEOS.

It is necessary to get the full PMT to get the CA descriptors

Could you please confirm whether this is supported or not? And if not, when would that be available?

Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
pmodem
Offline
Joined: 2008-12-17
Points: 0

The following SI APIs can be used to retrieve descriptors (outer and inner)

Each of these methods take a service handle which is also retrieved from SI DB given the right input params (ex: freq-prog-mode or sourceId etc.)
Ex:
mpe_siGetServiceHandleByFrequencyModulationProgramNumber(...)

For outer descriptors: mpe_siGetOuterDescriptorsForServiceHandle(...)

For inner descriptors specific to each component:
Retrieve all component handles first using
mpe_siGetNumberOfComponentsForServiceHandle(...)
mpe_siGetAllComponentsForServiceHandle(...)

Then loop thru each component to retrieve descriptors:
mpe_siGetDescriptorsForServiceComponentHandle(...)

Note: Its important to perform mpe_siLockForRead()
and mpe_siUnlock() before/after all SI calls.

rambalaraman
Offline
Joined: 2009-06-20
Points: 0

We, VividLogic, would prefer getting the full PMT information. This would enable us to support the current projects faster.

Could you consider modifying the mpe_podImplStartDecrypt() API to pass the tuner info, the program number and the raw pmt bytes, please?

This does not prevent CableLabs from providing better mechanisms in future.

Thanks!

pmodem
Offline
Joined: 2008-12-17
Points: 0

Adding a bit more clarification:

Method mpe_podDecryptStart() was recently added to RI trunk as part of POD implementation enhancements.

The CA descriptors are not filtered out by the stack. They are present in the MPE SI DB and can be retrieved by making appropriate SI DB calls before decrypt can be initiated.

amirn
Offline
Joined: 2009-05-06
Points: 0

Could you point me to which APIs in SI DB we need to use to get the CA Descriptors?

I looked at some APIs in MPE SI but they required native handle which I don't know how to get from mpeos_mediaDecode().

So with the mpe_podDecryptStart() and these MPE SI APIs I can see we could implement this in the java layer, before decode or buffering call is made.

Or we could leave java implementation as is, but make these calls in MPEOS *before* actual decode is performed.

cpratt
Offline
Joined: 2008-12-18
Points: 0

The decrypt call really should be performed from the JMF code - since there are stated ordering requirements between CA checks and parental control in OCAP (see OCAP 16.2.1.8).

Initially, the call to mpe_podDecryptStart() can be placed in Java_org_cablelabs_impl_media_mpe_MediaAPIImpl_jniDecode(). An SI handle can be retrieved via freq/program - which can be accessed via the tuner ID.

Message was edited by: cpratt

amirn
Offline
Joined: 2009-05-06
Points: 0

Thanks. That certainly makes sense and should be fairly easy to implement.

The pod API is actually mpe_podImplStartDecrypt().

I am assuming this will also need to be called for DVR.

amirn
Offline
Joined: 2009-05-06
Points: 0

We have thought about possible workarounds, but there is no easy solutions.

1. We could pass down the descriptors from java, in the case the service is encrypted. And have MPEOS Media and DVR handle them.
This would require changes across the whole stack.

2. MPEOS Media and DVR implementation could set filters based on the PMT PID
to re-acquire the full PMT so it can extract the CA descriptors.
This would require changes only to MPE/MPEOS, but will add processing delay in mpeos_mediaDecode() or mpeos_dvrBufferingStart()

An easier access to the PMT for the current selected service from MPE would be ideal.

Thanks.

cpratt
Offline
Joined: 2008-12-18
Points: 0

Hey Amir,

Have a look at mpe_podDecryptStart().

The intention is that this function is called ahead of mpe_mediaDecode() and mpe_dvrTsbBufferingStart(). It's currently stubbed out. But the idea is that this is what kicks off the CA_PMT construction.

sglennon
Offline
Joined: 2008-12-17
Points: 0

With the current use of the BOCR platform (internal to CableLabs only) for handling encrypted channels, where processing of the CableCARD and in particular handling of CA PMT descriptors is handled within the BOCR.

We understand that we need to expose the lower level CA PMT descriptors across the MPEOS boundary to support a more traditional low-level CableCARD stack on an embedded implementation and are actively looking at the design for that.