[streaming] Re: Fwd: Enterprise Ready Streaming On-Demand Server

[Armando Stettner]

Hi Martin.

Any idea why the encryption only works with MPTS?

   armando



Begin forwarded message:

> From: Martin Forget <mforget at mtotelecom.com>
> Date: November 18, 2006 1:20:25 PM PST
> To: streaming at videolan.org
> Cc: vlan at byu.edu
> Subject: [streaming] Fwd: Enterprise Ready Streaming On-Demand Server
> Reply-To: streaming at videolan.org
>
> hi... i am working on __exactly__ the same kind of setup in the  
> same context (cable tv operator planning an iptv launch)
>
>
> for DRM/Encryption, i suggest the DVB-CAS encryption that is built- 
> in vlc already.
> it works for both live and on-demand and adds somewhat minimal  
> overhead in processing power....
>
> --sout-ts-csa-ck <string>  CSA Key to encrypt
> --ts-csa-ck <string>  to decrypt
>
> works perfectly!
>
> it works only with MPTS streams (transport streams)
>
> i havn't tested this yet... but i think that for on demand streams,  
> you could encrypt them at encode
> time and it wouldn't add processing overhead at stream time.. will  
> test this shortly.
>
> at this point, you have to make your own key exchange  protocol  
> since none are included in vlc...
>
> i am planning on developping one in the next 2 months that is based  
> on 2 keys alternation with HTTPS key exchange
> and a PHP key server that access a mysql db for access control.
>
> which should be pretty secure (someone, pls correct me if i am  
> wrong)....
> note( even if PGP is open source.. doen't mean that files sent with  
> PGP aren't if you don't have the key!)
>
>
> one nice thing about DVB-CSA is that it's standard... so some  
> settops (like sigmadesigns 8635 based ones) have built-in
> decryption hardware for CSA ... (most embedded settops are probably  
> too weak to decrypt live on their CPU... they are VERY weak)
>
> for vod stream count capabilities... i don't know, but i am looking  
> for the same answer... i just ordered a mean machine to try this...  
> will keep the list updated with specs and results in couple of weeks
>
> (i am going to test  mpeg2+ac3 in TS and h264+aac in TS  using a  
> python rtsp server that controls vlm to stream unicast)
> note: i am testing amino + netgem + wegener settops )... that's why  
> i had to rebuild the rtsp server... they require TS streams
> and have non standard rtsp dialog.   also.... my server performs  
> custom authentication from mysql before streaming...
>
>
>
> -martin
>
>
>
> Begin forwarded message:
>
>> From: vlan at byu.edu
>> Date: October 4, 2006 11:12:26 PM EDT (CA)
>> To: streaming at videolan.org
>> Subject: [streaming] Enterprise Ready Streaming On-Demand Server
>> Reply-To: streaming at videolan.org
>>
>> I posted the following question on the forums.  It was suggested  
>> that I submit to the mailing list.
>>
>> ____________
>>
>> I have been a big fan of VLC for years and have always recieved  
>> good advice here.
>>
>> The company I work for is currently in the process of replacing  
>> our current cable tv offering with an IP television offering. We  
>> are going to use third party boxes to encode and stream the live  
>> feeds (to H.264 AVS I believe).
>>
>> In addition to this we want to add a Media on Demand system. I  
>> have been looking at different ways to accomplish this and I keep  
>> coming back to VLC. My immediate concern is scalability (we have  
>> close to 50,000 potential users).
>>
>> I thought I would post some of the basic requirements here and get  
>> the advice from the community. I'll start with what is expected  
>> from the end user's perspective.
>>
>> The end user will preferably have a single location (menu) where  
>> he can view both the available live TV feeds and the content on  
>> demand. This location should be accesible from both a PC/Mac/Linux  
>> and a set top box (connected to a television). In my opinion it  
>> might make sense to use a modified version of VLC for this. The  
>> content list provided to the user should be customized for that  
>> particular user (determined by some sort of authentication). The  
>> available feeds might be packaged as RSS. Now it is apparant that  
>> some sort of management system will need to be in place to sit  
>> between the streaming server and the clients. This management  
>> system will conatain all the eligibilty rules for each piece of  
>> media and will most likely present the customized list of content  
>> to the end user's client.
>>
>> Now there has been much talk about need for DRM to make some of  
>> our content providers happy. However when providing a "secure"  
>> stream, DRM seems irrelevant (correct me if I am wrong).
>>
>> Now on the server side we need something robust enough to handle a  
>> large ammount of simultaneous on demand streams. It is preferred  
>> that it has the ability to scale out (load balance streams across  
>> multiple servers). I have not found anything that can do this  
>> without a great deal of custom development (VLC inlcuded).
>>
>> Well this is the extremely high level overview. I am interested to  
>> see ya'll opionions as to where VLC might fit in as a solution.
>>
>> Thanks for your time.
>>
>>
>>
>>
>>
>>
>>
>>
>

-- 
This is the streaming mailing-list, see http://www.videolan.org/streaming/
To unsubscribe, please read http://www.videolan.org/support/lists.html