Development of conditional access plugin - best practice?

[nelliekins]

Hi,

I am trying to integrate an MPEG-2 TS conditional access system with VLC v1.0.x. My current implementation works as follows:

1. I have modified ts.c to provide a "conditional-access" parameter, and to use "module_need()" to load a generic wrapper plugin if the "conditional-access" parameter is set
2. I have written a generic plugin that provides a "ca" capability, and uses a very simple API to load and communicate with a DLL/.so that provides the actual crypto routines
3. In ts.c, I have modified Demux() and DemuxFile() to pass encrypted TS packets (as well as PSI data) into a method in the "ca" plugin (which in turn passes it into the DLL/.so)

All of this works flawlessly when playing a static file that has been encrypted. However, when receiving either a UDP multicast stream or using RTSP, I get _occasional_ successful decryption (appears to be content-related, in fact - certainly the same RTSP request will always give the same result). With UDP multicast, I usually get a blank screen (no audio). With RTSP, I usually get a blank screen (again, no audio either) for a period of approx 10s, and then the TEARDOWN occurs. I've found this timeout in modules/demux/live555.cpp, but can't seem to figure out _why_ it is happening.

My questions are:

1. Is this an acceptable method for integrating the CA platform (modify MPEG-TS plugin, use it to load a CA plugin, etc)?
2. Why does the LIVE555 plugin timeout after 10s when _encrypted_ RTSP content is streamed? (My best guess is that the LIVE555 plugin cannot read the encrypted payload - in which case I'm guessing it is incompatible with the likes of CSA, and my only solution would be to fix the LIVE555 plugin...)
3. Is there an alternative (i.e. _better_) method for integrating (and controlling loading of, and parsing TS data into) a new plugin of this type? If so, what is it?

TIA.

Neil.

[Rémi Denis-Courmont]

1. Is this an acceptable method for integrating the CA platform (modify MPEG-TS plugin, use it to load a CA plugin, etc)?

It seems sane, though you'd need to post the patch(es) to vlc-devel if you want in-depth reviews.

2. Why does the LIVE555 plugin timeout after 10s when _encrypted_ RTSP content is streamed? (My best guess is that the LIVE555 plugin cannot read the encrypted payload - in which case I'm guessing it is incompatible with the likes of CSA, and my only solution would be to fix the LIVE555 plugin...)

In my understanding, live555 aborts if it cannot receive any traffic. But I think it stops at the RTP layer, and does not do anything about the payload. Then again, I don't know the live555 internals.

3. Is there an alternative (i.e. _better_) method for integrating (and controlling loading of, and parsing TS data into) a new plugin of this type? If so, what is it?

Historically, the TS demux will pass the CA information to the access plugin via a private (ID_CA) control request. But that was designed for CAM hardware within DVB adapters and was only ever implemented by the Linux DVB back-end. That does not seem applicable to your scenario.

[nelliekins]

Hi Rémi,

Thanks for your feedback. I've just been looking at the source code in live555.cpp, and it calls a function "stream_DemuxNew()" (implemented in src/input/stream_demux.c) to connect to the TS demux plugin. I assume from the comments that it is designed to allow plugins to form "chains" for processing, which would seem to fit my need (which would be a chain of "rtsp" -> "ca" -> "ts"). However, live555.cpp hard-codes the "ts" entry, which means it is of little use to me!

I've also considered embedding the CA APIs into the TS demux directly (and removing the need for a separate plugin) - I guess this has more chance of success, although it isn't as clean / "neat" as a solution.

What about implementing an "access" module? Is it possible to "chain" multiple "access" modules in the same way as "demux" modules? Is there any documentation / HOWTO for writing "access" modules that I can read, or is it back to wading through the source code for an existing module?

Neil.

[Rémi Denis-Courmont]

I assume from the comments that it is designed to allow plugins to form "chains" for processing, which would seem to fit my need (which would be a chain of "rtsp" -> "ca" -> "ts"). However, live555.cpp hard-codes the "ts" entry, which means it is of little use to me!

There are many places where you can fit dechipering. I think the main restricting factor is the trigger mechanism. If there are no clues at the RTSP/SDP/RTP levels, then you have no business with the live555 plugin.

I've also considered embedding the CA APIs into the TS demux directly (and removing the need for a separate plugin) - I guess this has more chance of success, although it isn't as clean / "neat" as a solution.

I somehow doubt that would fix any issues per se.

What about implementing an "access" module? Is it possible to "chain" multiple "access" modules in the same way as "demux" modules? Is there any documentation / HOWTO for writing "access" modules that I can read, or is it back to wading through the source code for an existing module?

There are at least three ways to chain streams.

• stream_DemuxNew() pushes a stream to another demux plugin.
• stream_UrlNew() pulls data from another access plugin.
• stream_filter plugins can modify data coming from an access plugin.

But again, your options depends on the trigger mechanism, i.e. how do you differentiate a CA'd stream from a clear one.

[nelliekins]

There are at least three ways to chain streams.
stream_DemuxNew() pushes a stream to another demux plugin.
stream_UrlNew() pulls data from another access plugin.
stream_filter plugins can modify data coming from an access plugin.
But again, your options depends on the trigger mechanism, i.e. how do you differentiate a CA'd stream from a clear one.

At the most fundamental level, there are 3 triggers for our CA implementation (in order of preference / significance to our code):

1. conditional access table (CAT) (i.e. TS packet with PID 0x0001) with an appropriate conditional_access_descriptor
2. program map table (PMT) with an appropriate conditional_access_descriptor
3. ts_scrambling_control flag set on ES payload packets

However, the "ca" plugin is intended to be generic (i.e. to facilitate integration of other CA solutions besides our own). After all, the "ca" plugin uses VLC-specific prototypes and code, so it'll be GPL'd - may as well be as flexible as possible at the same time!

Anyway, my expectation was that the "Demux()" method in the "ts" demux plugin was the obvious place to listen for CAT/PMT/encrypted ES packets. However, it appears that expectation was flawed, as _something_ is blocking encrypted data from being passed to the "ts" demux plugin (and therefore never reaches the "ca" plugin). From what you're saying, my original approach is sound - I just need to figure out why it isn't allowing all the data through...

Neil.

[Rémi Denis-Courmont]

The in-band CA stuff is currently incoditionally passed from libdvbpsi to the underlying access (which really only works for Linux-DVB cards with a CAM module, I guess). Then the TS demux forgets about it, since deciphering is done in "upstream" hardware.

I guess the new plugin type makes sense. I don't know why it's failing though.

[nelliekins]

The in-band CA stuff is currently incoditionally passed from libdvbpsi to the underlying access (which really only works for Linux-DVB cards with a CAM module, I guess). Then the TS demux forgets about it, since deciphering is done in "upstream" hardware.

I guess the new plugin type makes sense. I don't know why it's failing though.

What is more confusing (to me at least) is that playback of an encrypted file from the local filesystem works perfectly every time. However, attempt to play the _same_file_ via RTSP (or IGMP streaming from a second VLC instance) and it doesn't work in most cases. Which is what makes me think that it isn't a problem with the "ts" demux plugin, but rather with the live555 code (although if that was the case, why would IGMP be affected?)

ARGH!

[nelliekins]

Ok, I am beginning to suspect that the IGMP+RTSP code in VLC is susceptible to the content of the stream. I have a repeatable situation whereby VLC will successfully decrypt and play an encrypted asset from a static file, and WILL NOT decrypt / play that same asset streamed over RTSP. The RTSP stream itself is perfectly valid, and can be decrypted on a suitably-configured AmiNET A110H running the decryption software.

It appears that the access modules are interfering with the "ts" plugin and its ability to receive and parse an encrypted MPEG-2 TS stream. Does anyone have a clue _why_ that would be the case?

If anyone has some time, I have made a suitable sample MPEG-2 file available. The MPEG-2 TS stream is encrypted at the TS level, and contains 1 audio and 1 video ES stream. It has valid PAT/CAT/PMT packets. The file is available for download from https://developer.useairware.com/~ncogg ... ic/test.ts.

[Rémi Denis-Courmont]

This probably not the best venue to debug liblive555...

[nelliekins]

This probably not the best venue to debug liblive555...

So liblive555 is responsible for access_udp implementation as well??? Because it happens with both RTSP and IGMP streaming...

[Rémi Denis-Courmont]

This probably not the best venue to debug liblive555...

So liblive555 is responsible for access_udp implementation as well??? Because it happens with both RTSP and IGMP streaming...

udp is udp. IGMP streaming does not exist. The VLC access_udp plugin is totally agnostic to the data.

[nelliekins]

udp is udp. IGMP streaming does not exist. The VLC access_udp plugin is totally agnostic to the data.

My apologies if I misphrased... Reception of a bare (as opposed to RTP-packetised) UDP multicast stream of an encrypted asset fails, whilst playback of the SAME encrypted asset from a local filesystem works 100% of the time. Additionally, the same multicast does decrypt and play successfully on a number of other systems (including but not limited to AmiNET A110H set top boxes).

I would be grateful if you can explain how this is possible if access_udp is agnostic... Is there something in libts that I have not understood that would cause this behaviour?

[Rémi Denis-Courmont]

You can check the code for yourself (modules/access/udp.c)...