gstreamer support for encrypted TS stream

Nicolas Dufresne nicolas.dufresne at collabora.com
Thu May 14 07:26:35 PDT 2015


Le jeudi 14 mai 2015 à 09:27 +0530, Nitin Mahajan a écrit :
> Hello,
>  
> Thanks to share your opinion wrt below for encrypted TS stream
> (MPEG2 TS with CAS) usecases with gstreamer
>  
> example pipeline with playbin will be something like this-
> dvbsrc -> recorder -> decodebin -> xx
> 
> (1) Pipeline Creation Issues with Encrypted TS streams where TS
> header is also encrypted with playbin. Typefind element at entry of
> decodebin, the "force-caps" property can be set to run in bypass
> mode but then it would still require patch inside playbin/decodebin
> to force connection of typefind with mpegtsdemux (content is
> encrypted) and for other media containers (mediaplayer) we let
> typefind work as usual and find the suitable demuxer.
If TS is encrypted, then your source should set difference media type,
so playbin can plug a decrypter before the demuxer. If the TS is not,
ideally this should follow a standard for TS file, and caps should
reflect that in a way that the decoder won't be considered enough, so
playbin will plug your decrypter. If this encryption is custom (non
-standard), then I'd say the right approach is to replace/wrap the
demuxer into your own, with a higher rank.
HLS encrypt files, instead of container packet, this is also a good
solution. Key exchange and stuff is all kept at higher level.
>  
> (2) Another scenario - TS Header not encrypted but payload encrypted. Here it is expected that TS typefind can work without problem > Or instead of playin, start exploring customized pipelines with complete functionalities similar to playbin..
This is the play-ready technique iirc. The idea is that demuxer, and
parsers will work as usually. Seeking code isn't affected either.
Though, if not done well, the decoder and the decrypter can be
confused. Again, something in the container should be reflected in the
caps in order to force the need to plug the decrypter before. Most
likely only standards will be accepted upstream (so far nobody seems
to agree on anything)
Hope this helps a bit,
Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150514/c5dd1c86/attachment-0001.html>


More information about the gstreamer-devel mailing list