TV stream and scrambled channels

TV stream and scrambled channels

Post by David Olss » Wed, 22 Feb 2006 22:41:08


I've writing an application which is able to communicate with my program
card/smart card provided to me by my DVB TV distributor so that I can
subscribe to Pay TV channels. This application is able to query the
smart card for key to descramble the TV channels I subscribe to. I do
however have no connection between my "software CA-module" (as one might
call it) and the TV-tuner (its a DVB-T tuner). The DVB-T tuner I have
come with BDA driver so it should work fine with DirectShow. My question
is however this; is it possible to access the scrambling information
sent in the mpeg2 transport stream's PES packets through the DirectShow
API somehow so I can send it to the smart card? And is it futhermore
possible to feed the descramble key returned by the smart card back to
the mpeg2 decoder so that the scrambled channels gets decoded correctly?

Thankful for all answers! Best regards
/ David Olsson

TV stream and scrambled channels

Post by Peter Feld » Thu, 23 Feb 2006 19:32:40

"David Olsson" < XXXX@XXXXX.COM > schrieb im Newsbeitrag

If I understand you correctly, you're communication with your smart-card by
some kind of SC-Interface _other_ than a CA-Module?

It certainly is possible, e.g. using the sample-grabber or a custom
transform-filter. You would have to insert it after your BDA-capture-filter
(not the bda-tuner), or possibly behind the MPEG2-Demux-filter, but
certainly before any MPEG2/Audio-Decoder.

This way you can access the raw TS (including all information
scrambling-information ca-sections, scrambled packets) or only specific PIDs
(if you insert your filter behind the demux).

You will however have to "read" any information you need out of the "raw"
ts-packets - MS-Digital-TV infrastructure knows nothing about

No. In a regular (and possibly the only legal) scenario the CA-Module will
do all that - talking to the smart-card, reading CA-information, determining
the correct descrambling-key and descrambling the affected packets (or at
least telling the demux the CW for descrambling packets - not sure who
actually does the XORing) - you are not expected to get access to any
descrambling CWs anywhere along the TS-data-path.

But definitely neither the ms-mpeg2 demux nor _any_ mpeg2-decoder know about
descrambling any data/pes-packets. They simply expect correct data at their
input-pins. (however the demuxer is able to pass through scrambled packets,
since it doesn't actually care about the embedded data). So with DVB-cards
supporting CI-slots the driver will ensure that the data that gets out of
the BDA-capture-filter is already processed correctly (by passing though the
CAM beforehand).

So for your "software CI" to work you will also have to do the actual
descrambling yourself (which is basically nothing but a simple
xor-operation) - there are some dvb-s programs out there that implement an
interface for software-cams - you could have a look at their source-codes
(basically they take each 188byte-packet coming in with the TS, examine it
if it has to be processed/process it and then pass on the modified packet)

Be aware that legally you're on very thin ice (if not to say that you're
already under water;)
Peter Feldbaumer
p dot feldbaumer at utanet dot at


TV stream and scrambled channels

Post by David Olss » Fri, 24 Feb 2006 06:23:55

Thanks a lot for your reply. It was extremly helpful! Just a couple of
more questions though... ;)

Peter Feldbaumer skrev:

Exactly! I'm using a smart card reader which was included with a laptop
I purchased a couple of years ago...

Ok, this makes sense! I just need to study the mpeg TS specifications to
recognize certain interesting packets.

But what if I have a DVB tuner with embedded mpeg-decoding? Will such a
tuner even allow scrambled packets to leave the BDA driver if the tuner
isn't able to decode them? Or will all packets be sent along to the
filter graph and, if neccessary, be handled by my and all other filters
and then fed back to the hardware decoder by a filter further down the
filter graph?

I guest that, if I really had a DVB tuner with hardware mpeg decoding, I
could test what kind of filters a filter graph that displays a TV
station from the DVB stream is made up of this using GraphEdit?

Best regards
/ David Olsson

TV stream and scrambled channels

Post by Peter Feld » Fri, 24 Feb 2006 08:45:27

"David Olsson" < XXXX@XXXXX.COM > schrieb im Newsbeitrag

yes, all the information is out there - esp. iso13818 and some more
documents from etsi(.org I think)

I think you're mixing up hardware _decoding_ (which would result in an image
ready to present on screen) and hardware _demuxing_ (which "pre-selects")
which packets to transmit out of the bda-capturefilter.

If you really have hardware-mpeg2-decoding (which e.g the technotrend dvb-s
_premium_ line has) then you're completely out of luck, unless the
bda-drivers would present to you some kind of custom interface for supplying
descrambling-CWs. I do know of _NO_ card/driver that has these caps (nor do
I think there would be a legal use for such an interface).

If your card can do hw-demuxing (which almost all dvb-capture _hardware_
COULD do, but almost no driver implements), then this should not influence
any scrambling/descrambling you wanted to do with the resulting stream.

If your card has hw-mpeg2 _decoding_ then you won't be able to test this
with graphedit, because this is certainly implemented by some means
_diffferent_ from standard ms-digital-tv/bda graphs...
Even hw-demuxing will be hard to test with graphedit, because you most
certainly will have no UI to configure the hw-demux. Only the ms-mpeg2-demux
presents such an interface (which pids to map). However a complete BDA-graph
with Network-Provider and BDA-TIF might work in graphedit.
Peter Feldbaumer
p dot feldbaumer at utanet dot at

TV stream and scrambled channels

Post by David Olss » Fri, 24 Feb 2006 16:13:15

Nope, no mix-up. :-) But I haven't considered hardware demuxing. Would a
DVB tuner implementing hardware demuxing simply not send scrambled mpeg
packets through to the filter graph? Or does it mean that it only sends
the current TV station stream through to the filter graph?

So how would this work with DirectShow? A filter graph consisting of a
source filer (a BDA-hw-mpeg-capture-filter) which outputs decompressed
video and audio data ready for rendering and a video sink and an audio sink?

TV stream and scrambled channels

Post by Peter Feld » Fri, 24 Feb 2006 16:56:54

"David Olsson" < XXXX@XXXXX.COM > schrieb im Newsbeitrag

I'd guess it depends on the actual implementation... The better definition
for what I meant with hw-demux should be "hw-packet-filter" - it shouldn't
care about the contents of single packets at all - the more "high-level" the
functions of the demuxer get (e.g. attaching time-stamps to samples,
rebuilding complete pes-packets...) the more likely they will fail, since
informations of the _descrambled_ stream are needed for this kind of
If your hw-device tries to perform such high-level operations, it will most
likely discard all packets it can't understand (because they're scrambled) -
if it simply outputs packets with pid x on pin x and packets with pid y on
pin y then it should work.

May I ask what kind of device/card you have that you think performs

Most likely this is implemented with no graph at all (e.g. technotrend
dvb-s _premium_ only exposes a custom sdk, no bda-drivers).
If anything at all, it would work with some kind of overlay-surface (where
the decoded video-frames get copied to the graphics-card directly) - I
personally have never seen a bda-capture-filter output pin with anything but
a full (or partial) mpeg2-ts - any decoded output-pin would present a
_massive_ load on the system, since you constantly would have to transfer
768x576x24Bitx25fps = 32MB/s from your pci-card or usb-device... If at all
it can only work by using direct-memory transfer to the graphics-card. Then
the components of the graph should be "wrapped" in dummy directshow-filters,
presenting a "regular" graph to the system, but the actual samples (bytes)
never leave the card - with such a graph you also won't be able to insert
the sample-grabber or a custom-transform filter into the graph.
Peter Feldbaumer
p dot feldbaumer at utanet dot at

TV stream and scrambled channels

Post by David Olss » Fri, 24 Feb 2006 17:09:42

Actually I don't have a hw-decoder tuner. Just thinking ahead... :-)

Ok, that makes sense!

Thanks a lot for all your help Peter, your input has been extremely

Best regards
/ David Olsson

TV stream and scrambled channels

Post by Peter Feld » Fri, 24 Feb 2006 18:00:29

"David Olsson" < XXXX@XXXXX.COM > schrieb im Newsbeitrag

you're welcome!
Peter Feldbaumer
p dot feldbaumer at utanet dot at

TV stream and scrambled channels

Post by RGF2aWQgT2 » Wed, 10 May 2006 19:11:02

I've recently seen that an interface called IBDA_ConditionalAccess has been
added to the BDA. Will it be possible to use this to implement CA modules or
what is its purpose?

Best regards
/ David Olsson

TV stream and scrambled channels

Post by Peter Feld » Wed, 10 May 2006 22:02:12

"David Olsson" < XXXX@XXXXX.COM > schrieb im

I don't think any additional info on this interface has been published (at
least I don't know of any)...
Following its name I'd guess it will have something to do with CA-systems
(however I don't know if will apply to nowadays "european" CA-systems or
something "american") - from the (lack of) methods I'd guess it can only be
a very "high-level" interface to any ca-system...
Peter Feldbaumer
p dot feldbaumer at utanet dot at