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

Sun Nov 19 22:39:02 CET 2006

the crypt/decrypt code is  part of the ts.c and sout/ts.c  sources  
files... so i guess it only works in ts containers.

also... csa encryption is a standard part of dvb which is 100% mpeg- 
transport-stream based... so it's kind of logical

note: you can fit many different video/audio codecs in a ts  
container....

On 19-Nov-06, at 1:19 PM, Armando Stettner wrote:

> 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
>

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