[linux-dvb] Re: Linux DVB API 4 Q's

[Rob.McConnell@Zarlink.Com]

Hi Again,

A few more Q's regarding the V4 API...

> > Have a few Q's about the header files in the V4 API dir in CVS:
> >
> > 1: I see that the "dvb_dmx_source_format" has a new format called PES.
Is
> > this to cover proprietary formats such as AVPES?

> No, we don't care about AVPES anymore. That's left for userspace.
> PES means a stream of video + audio (and maybe other) PES packets
> without (PS) pack structure. I'm not sure if that's really needed
> but someone wants it.

I guess the demux device in this case would filter on the stream ID and the
complete PES packet would be delivered
to either the h/w decoder or a circular buffer.  Would a Program Map Table
be transmitted as well to determine what
is being transmitted?

> > 3:  For the DVB_DMX_SET_PID_FILTER  syscall option 2 (not using the
add/del
> > pid IOCTLs), if we set all the PIDs up at once then they would all have
to
> > have the same type, output format and share the same flags.  Now the
same
> > type and output format are OK, but if you want to prioritise one PID
over
> > another using the HIGH/LOW priority flags, then this becomes a problem.
> > Basically, if you wanted to have different flag values for the PIDs
then
> > having this single IOCTL to set all the PIDs at once would be a
problem.  I
> > can see that it certainly simplifies the overall code, but I would
favour
> > having the ADD/DEL IOCTLs instead as this gives more flexibility to the
> > user programs.

> Hm, so there's a difference of per-PID flags and per-file descriptor
> flags. I'm open for both solutions (i.e. SET vs. ADD/DEL), but I think
> SET might be simpler to implement and use. We could have something like:

>   struct pid_flags {
>              uint16_t pid;
>              uint16_t flags;
>   };
>   struct dvb_dmx_pid_filter {
>              ...
>              struct pid_flags pids[MAX_NUM_PIDS];
>              ...
>              int flags;
>   };

Could you run through the advantages of the SET ioctl over the add/del.
Personally I would still rather stick with ADD/DEL as user applications
would typically use these methods to set up PES filters when changing a
programme or as and when required.  I guess the SET ioctl would only
benefit if you had quite a few PIDs that you knew beforehand to setup, but
once you had set them up, would you still use the SET ioctl to add >1 PIDs
again? What about channel changes - are there many PIDs to be setup at once
or individually? Maybe having both interfaces would be best... what do
people think?

> I thought they are not needed for PID and SID filters (the PID/SID is the
id).
> For section and sid filters, I think *I* don't need multiple filters per
file
> descriptor. If you really want them, protest load enough ;-)

As long as we have the capability to add multiple PID filters to an fd for
a TS or PES output, then that should be OK (e.g. for recording to HDD).
For section filtering, I suppose it would make sense to have different fds
for the same PID but different table id.  Is this the intention here?

> Audio is difficult, because I don't have a clue. We (== Convergence)
> currently do mixing via a simple OSS device, and I thought about the
> possibility of using parts of ALSA for more complex audio post
> processing options.

> If we could create an API which works for all of us I would like to
include
> it in the DVB API.

For audio h/w (e.g. DSP), status information would normally be returned in
a register or memory location.  I guess
access to this register would have to be done via a read syscall or we
could setup an audio event to watch.  OK, we would need to cater for AC-3,
LPCM, DTS, AAC, OGG, MPEG-1, MPEG-2 (inc. multichannel) and any other audio
standards.  How do we want to proceed next?


*** Now for the new Q's: ***

A. If we want to route a TS/PS/PES off a DVD or HDD through a PID filter,
then I guess we would have to setup the source type of the filter to be
"DVB_DMX_SOURCE_FRONTEND" with the correct "frontend_num". The same goes
for an input from an external C/A modules or LVDS, etc.  Is this the
intention?  Does the term "front-end" really make sense?

B. In s/w, I need a means to route a TS from say an external demod to an
external descrambler hanging off the common interface.  Also, I need to be
able to select the source type for a PID filter to be from this C/I.  Can
we add a source selection ioctl for the C/A or C/I?

e.g. DVB_CI_SET_SOURCE or DVB_DMX_SET_CI_SOURCE

This could use the "dvb_dmx_src_type" as the input source selection.

What about catering for multiple C/I or C/A modules? Should we have a
logical device for each C/A and a source selection ioctl as above?  For
example, C/A module #1 could have a feed from demod #1 and C/A module #2
could have a feed from demod #2.

Where conceptually does the C/I or C/A sit in the flow of data from a
front-end in terms of the API? Does it sit between the frontend and demux
like it should?

C. Why have the filter types TELETEXT and SUBTITLE been removed?  If
someone has a dedicated piece of h/w to do SUBTITLE or TELETEXT decoding
then shouldn't we still have this option here?

D. If h/w can generate an interrupt when we have received a full packet
(PES level filtering) or when a certain number of bytes have been
delivered, how does the API allow this threshold to be set?  For example,
should we have an API ioctl similar to the DVB_DMX_SET_BUFFER_SIZE ioctl to
allow a threshold to be set before the h/w or s/w filtering should call the
cb function?

e.g. DVB_DMX_SET_BUF_THRESH   0 = none, 1 = one packet, 2 = two packets,
.... 65535 = max packets.

OR what about taking a percentage of the buffer size

e.g. DVB_DMX_SET_BUF_THRESH   0 = none, 1 = one packet, 2 = 25% , 3 = 50%,
4 = 75%, 5 = 100%

Take another example of s/w filtering of a subtitle stream.  If we have a
fixed threshold of say 32768 bytes before the callback function is
activated, then we will be too late to deliver the data to the user process
- the A/V data will have passed a long time ago.  On the flip-side if we
are trying to demux a video PES into memory and we have a buffer fixed at
188 bytes, then we will have lots of interrupts occurring and the callback
function will be v. busy.  If the buffer threshold was set to 32768 in this
case, then we would receive fewer interrupts and less calls to the c/b
function and the cpu would have more time to do "other things".

Also, the filter type such as SUBTITLE or VIDEO would be useful to know how
to handle the data (buffer size, c/b function, etc.).

Any thoughts?

E. How does the NEW dvb_dmx_event system work in terms of returning an
event such as
DVB_DMX_RECORDING_EVENT_I_FRAME found?  Surely if you have a user level
process blocked on a wait queue waiting for this specific event to occur,
then by the time it does unblock, the event would have passed some time
ago.  If you were wanting to use this "event" to record some information on
a HDD as to where this I-frame is, then because the process is unblocked
"too late", this information is not so useful.  What are the intentions of
this API call and what is the field "bytes" in struct "dvb_dmx_event" used
for?

F. In the ioctl "DVB_DMX_GET_STC", surely there is a difference between the
actual STC value and the one returned due to inherent delays in Linux.  If
user apps were to use this returned STC value for say subtitle
synchronisation, then surely there would be some jitter that may result in
the subtitles being displayed at slightly the wrong time.  Does this happen
in reality?

If h/w had an STC compare interrupt in which a "DVB_DMX_SET_STC_CMP" ioctl
would set a register that was automatically compared with the STC, then you
would still have the problem of notifying the user-level process that the
STC compare event occurred.  Which is quicker, sending a process a signal
(e.g. SIGUSR1) or having the process wait for an event to occur?

Would it make sense to have the ability to have a DVB_DMX_SET_STC_CMP ioctl
for h/w that uses it?  For h/w that didn't support it, you could stick with
user-level timers.

G. From a top-down approach, how does the demux descrambler API function?

That's all the Q's I have for the moment, I hope they make sense.  If not,
then please let me know - there are still a few grey areas that I need to
cover with you.

Many Thanks,

Rob : )






-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.