gstreamer support for encrypted TS stream

[Holger Kaelberer]

Hi

On 14.05.2015 16:26, Nicolas Dufresne wrote:
> 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)

This is the case for (at least) some pay-TV DVBx sources, when you miss a hardware decoder. Then you 
get a MPEG TS stream with transport_scrambling_control set (ISO/IEC 13818-1, 2.4.3.3).

When last checked, tsdemux dropped all such packets early, before even parsing adaptation field.

(Though, usually for such sources you're supposed to use a receiver/decoder from your provider.)

Holger