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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
