Hi Laurent, Now that we have a patchset enabling the media controller for DVB, I'm facing with some issues related to media streaming that are different than what happens at the V4L side. I took some time to write a small text that describes the DVB from the PoV of the media controller, and showing some issues I'm currently facing. Please take a look. Perhaps we could discuss it on a next Media Summit, as some of the issues there seem to require some changes at the media controller side. What do you think? PS.: the described scenario on this document is far from being complete. This is just a starting point for discussions. Regards, Mauro --- DRAFT: DVB and the Media Controller DVB DEVNODES ============ At the DVB API, there are multiple DVB devices that are used for different purposes. A typical device with just one adapter and just one frontend would be mapped as: /dev/dvb/adapter0/frontend0 - frontend devnode /dev/dvb/adapter0/demux0 - demux devnode /dev/dvb/adapter0/dvr0 - DVR devnode If such device has a CA module (responsible to decrypt streams), an extra devnode appears: /dev/dvb/adapter0/ca0 - CA devnode If the device is hybrid, it will also have a V4L2 device, like: /dev/video0 TUNER SUB-DEVICE ================ Just like analog TV devices, DVB devices have a component that tuners into a channel. On DVB, the component responsible to tune into a channel and decode the physical layer is called frontend. However, several non-hybrid DVB devices don't have a tuner subdev, due to two reasons: - Sometimes (like Satellite systems), the tuner is integrated with the frontend device; - Several devices use a micro controller to setup both tuner and frontend at the same time. So, the tuner is invisible to the Kernel. Hybrid Analog/Digital devices always have a tuner, as the same tuner is used for both analog TV and as part of the digital TV frontend. In this case, the tuner subdev may feed either the DVB frontend or the analog demod subdev, but never to both at the same time. MEDIA STREAMING =============== As the DVB devnodes are independent, the concept of "media streaming" is actually split into each specific devnode. a) frontend streaming When the frontend devnode is opened and a FE_SET_PROPERTY ioctl (or the legacy DVBv3 ioctl) is called, a thread is started inside the DVB core. Both tuner and frontend start streaming at this time. However, the MPEG TS is not delivered yet. What happens here is that it tries to lock at the TV physical channel. Via the frontend interface, it is possible to check the status and the QoS parameters related to the tuning and to the DVB error measurements. b) MPEG-TS streaming The MPEG-TS streaming is commanded via the demod devnode. It happens by setting a filter that will be applied to the MPEG-TS. There are two types of filters: one for MPEG tables, and another one for MPEG programs. When a filter is created, a dynamic stream is created, and will contain all the packet IDs (or tables) that match the filter. Both the input and the output can be directed to different devnodes, depending on the parameters that are given to the ioctl. Typically, it uses the frontend devnode as stream input[1], and the dvr devnode as output, although it is possible to get the output also at the demod devnode[2]. [1] http://linuxtv.org/downloads/v4l-dvb-apis/dvb_demux.html#dmx-input-t [2] http://linuxtv.org/downloads/v4l-dvb-apis/dvb_demux.html#dmx-output-t While in general just a few filters are set, the drivers generally allow a big number of filters, like 256. Some hardware even allow to dynamically allocate and change the max number of filters at runtime, reallocating filters from one adapter to another one. The CA interface is something that requires change. Originally, it was just a control interface to handle CA, but some devices implement it as a completely separated independent module that can even decrypt a TS that was, for example, stored in the disk. So, from the media pipeline PoV, this can be dynamically added in the middle of an streaming pipeline. TYPICAL USECASE =============== As can be seen from the above, the are multiple streams happening at the DVB API: 1) the frontend streaming; 2) the per-filter streaming. And they're started/stopped at different times. A typical DVB application will initially create one pipeline: tuner --> fe Once the FE locks and has an stable connection, the DVB application will create other pipelines. For example: pipeline 1: Track the MPEG-TS control tables (PAT, PMT, ...) pipeline 2: Audio Program Elementary Stream pipeline 3: Video Program Elementary Stream So, it will have: tuner --> fe --> demux --> dvr filter 0 tuner --> fe --> demux --> dvr filter 1 tuner --> fe --> demux --> dvr filter 2 If the user wants, for example to see the closed captions, an extra pipeline will be created: tuner --> fe --> demux --> dvr filter 3 (for CC) Let's now assume that a given program is DRM-protected and needs to pass through the CA subdev. The pipelines should be dynamically changed to: tuner --> fe --> demux --> ca --> dvr filter 0 tuner --> fe --> demux --> ca --> dvr filter 1 tuner --> fe --> demux --> ca --> dvr filter 2 Btw, it is possible to have both encrypted and unencrypted programs inside the same MPEG TS. So, we may have things like: tuner --> fe --> demux --> dvr filter 0 tuner --> fe --> demux --> dvr filter 1 tuner --> fe --> demux --> dvr filter 2 tuner --> fe --> demux --> ca --> dvr filter 3 tuner --> fe --> demux --> ca --> dvr filter 4 tuner --> fe --> demux --> ca --> dvr filter 5 (in the above example, one program could be recorded while the other one could be displayed). KNOWN ISSUES WITH MEDIA CONTROLLER API ====================================== 1) dynamic creation/removal of pipelines This is needed to allow mapping each DVB filter as a pipeline. 2) media_entity_pipeline_start It should be possible to pass not only the start entity but also the final entity, as it should be possible to control tuner/fe pipeline independently of the demux filter pipelines. 3) pipelines with audio and DRM (I'm adding this one just to make this document complete) This was discussed already at last Media Summits, but assuming that both audio and DRM will use the media controller, it would be interesting to be able to setup a pipeline between the different subsystems. This is not an issue for DVB and V4L2, as the bridge driver can easily share the media device between the two subsystems, as I did on my experimental patches, but for audio this is an issue, as devices that implement standard Audio Class don't use the media driver for audio, but, instead, snd-usb-audio. Perhaps we could add a function that would allow to get the mdev based on the parent device struct, in order to allow re-using the mdev on different subsystems. This would help with audio, but not with DRM. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
