dvb: discussion: future of dvb
Edward Hervey
bilboed at bilboed.com
Thu Apr 24 02:26:20 PDT 2014
Hi,
On Tue, 2014-04-22 at 16:53 +0200, Stefan Ringel wrote:
> What do you think about:
>
> 1. change dvbchannelparse to dbus service
That would be a good idea indeed.
Note that the implementation isn't what matters most here (at least
from a GStreamer pov). The idea would be to have a daemon running which
analyses at regular interval the various adapters/programs, which other
processes could query information about.
The only thing the gst dvb element would need is:
* What are the various parameters to tune to a given channel:
* adapter, frontend, delivery system
* tuning parameters
* Program ID
* Information from the PMT (which PID to use,...)
Some ideas of other stuff that could be queried (but not mandatory for
proper dvbbasebin behaviour):
* List of all available channels per adapter
* PMT (or equivalent information) for a specific channel
* EPG ? :)
> 2. add ci+ part to cam implements
What does that imply from a gst point of view ?
> 3. I missed interaction between user and ca-module
> - sending information/warnings to the user
> - pin rqeuest/replay
> - certification part
> - firmware update
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).
> 4. an equalant to dvbsrc for microsoft name bdasrc
Definitely :)
> 5. oipf.tv/hbbtv implementation inlc. webkit
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.
> 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
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.
Edward
>
> I hope I have not missing.
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
--
Edward Hervey
bilboed at bilboed.com
More information about the gstreamer-devel
mailing list