<html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15"> </head> <body bgcolor="#FFFFFF" text="#000000"> Am 24.04.2014 11:26, schrieb Edward Hervey: <blockquote type="cite" style="color: #000000;">Hi, On Tue, 2014-04-22 at 16:53 +0200, Stefan Ringel wrote: <blockquote type="cite" style="color: #000000;">What do you think about: 2. add ci+ part to cam implements </blockquote> What does that imply from a gst point of view ? </blockquote> ci+ (common access interface plus) (TS 103 205 v1.1.1 from 3/2014) is the next generation of ci specification (EN 50221). It controls scrambling mpeg-ts streams, the access to recording (DRM), time-shifting, output (analog, hdmi, lan) etc. -> filesink, filesrc, rtpsink, videosink etc. -> for lan look to point 5. and 6. . <blockquote type="cite" style="color: #000000;"> <blockquote type="cite" style="color: #000000;">3. I missed interaction between user and ca-module - sending information/warnings to the user - pin rqeuest/replay - certification part - firmware update </blockquote> Tricky. Would require extending the mpegts library to support that. This is also something that doesn't need to be handled *in* GStreamer per-se (you can just open the cam device from elsewhere and handle that yourself). </blockquote> the communication between host and module are not mpegts sections. And we can't open a ca-device in dvbbasebin and a outside apps in the same time. What I'm meant was simpler: a callback funktion holder in dvbbasebin (like ca_request (ca_massge_type, data) ) and a reply method (like ca_reply (ca_massage_type, data) ). sometimes a ca-module ask for additional PID's which dvbbasebin must set. <blockquote type="cite" style="color: #000000;"> <blockquote type="cite" style="color: #000000;">5. oipf.tv/hbbtv implementation inlc. webkit </blockquote> Or rather : expose dsm-cc via the mpeg-ts lib. The usage of it is out of scope, but providing that information from the mpeg-ts lib is definitely in scope. I have some WIP regarding dsm-cc support in mpeg-ts lib, will refresh it at some point. </blockquote> that is not true. oipf.tv/hbbtv don't based of dsm-cc. oipf description the same like dvb-iptv/dvb-hn specs inlc. isdb and atsc (DAE - Declarative Application Environment). oipf and hbbtv are based of html5 and javascript (edge apps are signalled in PMT -> application_signalling_descriptor and is a web url). oipf.tv specs v2.3: -Functional Architecture -Volume 1 Overview -Volume 2 Media Formats -Volume 2a HTTP Adaptive Streaming -Volume 3 Content Metadata -Volume 4 Protocols -Volume 4a Examples of IPTV Protocol Sequences -Volume 5 Declarative Application Envvironment -Volume 5a Web Standards TV Profile -Volume 6 Procedural Application Environment -Volume 7 Authentication Content Protection and Service Protection -Profile -Schemas <blockquote type="cite" style="color: #000000;"> <blockquote type="cite" style="color: #000000;">6. dvb-hn (brigde dvb to home-network) and the same for isdb and atsc - dvb-iptv - bcg - bridge upnp/dlna - dvb-cpcm (Content Protection Copy Management) - interactivity inlc. docsis / eurodocsis / ocap - firmware update - metadata </blockquote> All of those seem to be things to be handled outside of GStreamer. If some descriptors/sections need to be parsed/exposed to handle those use-cases then that's fine, but the actual handling should be done in a separate app. </blockquote> Edward, do you handling drm (dvb-cpcm) stuff outside gstreamer? Is that unsave / save? And which part should published service/epg data over network and mounting it to rtsp-server? the same above in 5. all dvb spec are included in oipf.tv specs. List all dvb specifications: DVB-IPTV (TS 102 542-1 - TS 102 542-5, TS 102 034 (BlueBook A86, BlueBook A166), TS 102 539 TS 102 826, TS 102 905 (DVB-HN), BlueBook A115, TS 102 824, BlueBook A128, TS 102 685, BlueBook A144, TS 102 809, BlueBook A145, TS 102 905) DVB-CPCM (TS 102 825-1 - TS 102 825-14) Stefan Ringel </body> </html>