> -----Original Message-----
> From: Kevin Marks [mailto:email@hidden]
> Sent: Wednesday, November 08, 2000 11:32 PM
> To: Moreillon Guy; DSS Dev List (E-mail)
> Subject: Re: Streaming scrambled movies
>
>
> At 4:10 PM +0100 11/8/00, Moreillon Guy wrote:
> > The way I've been going so far is to use the sample code for the
> >packetizer and reassembler and add my scrambling code: the packetizer
> >scrambles the video stream as it packetizes during the
> hinting process and
> >the reassembler does the opposite during the playing
> process. This is OK
> >except for a few problems:
> > + the original video stream is not scrambled in the
> quicktime movie file,
> >the scrambled version is in fact stored in the hint track,
> so the movie can
> >be seen directly on the server using a regular client. I
> have to write my
> >own app to hint the movie and somehow erase or nullify the
> original video
> >track.
>
> No-one should be able to see these files on your server if its just
> running QTSS.
Sure, but the movie would be scrambled at location X, transfered to
location Y and streamed without further transformation from there.
There is a security hole between X and Y (and even at Y, no computer
system is secure). We could secure the transfer between X and Y, but
this adds handling. In any case we've now managed to remove the
original movie track and keep only the hinted movie track which is
played without a hitch by the server, so this works fine.
> > + this only works for the YUV2 video encoding since it is
> the only format
> >for which I have a packetizer/reassembler source code
>
> You need to generalise your packetisation/reassembly code, to be more
> like the QT packetizer (which will pack any data type). It works by
> just chopping up the media data into packets, and sending a
> SampleDescription every now and then.
I had in mind to keep the specialized packetization algorithms of each
media type so as not to lose on the quality of the broadcast. That is
the whole idea of having specialized packetizers and reassemblers
isn't it? If I packetize/reassemble a Sorenson video stream using the
base packetizer/reassembler, wouldn't I lose on quality in case of
packet loss for example? Or would that be negligeable?
> > I've been thinking about another solution however, and
> this is where the
> >gurus come in: if I could replace the regular Packet Builder
> with my own
> >scrambling packet builder, my solution would be totally
> independant of the
> >media (huge plus) and I'm pretty sure I could do this by
> capturing the
> >Packet Builder component. But this leaves the problem of the
> unscrambler on
> >the client side. Is there an equivalent to the Packet
> Builder on the client?
> >That is, a generic component that handles the packets at
> some point before
> >they are passed on to the reassembler, a component that has
> methods that can
> >easily be rewritten to include the unscrambling treatment?
> >
> > Or, is there another simpler solution???
>
> This sounds like a bad idea, as you would be sending packets
> purporting to be QDesign or H263 which instead contain noise, which
> will likely crash a client without your reassembler.
True. This might not be a problem in the context where this solution
would be used, but it is true in the general case.
> Instead, why not define a custom packing format that works by
> embedding the true packing format in the packets, followed by your
> scrambled data. You can use your devious packet-builder capture
> scheme on the encoding end, but on the reception end you just open an
> instance of the reassembler you need to decode you packets and pass
> it the descrambled ones.
I'm not sure I follow you. The way I understand what you are saying is:
I should capture the packet builder and instead of just scrambling the
payload of the packet, I should put in my own header in the packet,
followed by the original header, followed by the scrambled data. Then,
on the client side, I should pull out of the received packet the original
header, unscramble the data, put this together, and pass this on to the
appropriate reassembler.
What don't understand is, in which component do I put my code on the client
side and how do I know which reassembler to call? Or from another point of
view: at the packet builder level, do I have any mean of knowing what kind
of media I am currently packing, and can I change this media so that my
custom made reassembler will be called to reassemble it (in fact changing
the media back to its orignal type, unscrambling the data and calling the
real reassembler).
Sorry if I seem a little confused, but the fact is, I am.
If you could detail your suggestion, it would be huge help.
Thanks a lot.
-- Guy Moreillon
-- Software Engineer & Project Manager
-- NagraVision, Kudelski SA
-- Tel: +41 21 732 04 47
