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

[Johannes Stezenbach <js@convergence.de>]

Hi,

lots of questions, so it takes some time for me to go through them,
but they are highly appreciated!

Rob.McConnell@Zarlink.Com wrote:
> > 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.

Yes.

> Would a Program Map Table
> be transmitted as well to determine what
> is being transmitted?

No. Muxed PES playback is mostly a legacy of VDR on av7110 based PCI cards.
Normally one wants to have proper time stamps, i.e. TS with PCR in
adaptation fields or PS. The av7110 can't handle TS/PS playback, but
wants PES. Rather than emulating it in the driver we want userspace to
deliver what the hw (or av7110 firmware) can do.

> 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?

See my other posting. Current software uses on fd per PID, so it doesn't
matter. IMHO it matters only for stream recording. But I note your and
Ralphs preference, so I guess I'll go with ADD/DEL.


> For audio h/w
[snip]

I'll start a new thread for that to seperate it from the demux
discussion.


> *** 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?

My thinking was to use DVB_DMX_SOURCE_MEMORY, because we use the
usual Linux file systems. We read() from a TS file into some
buffer in memory, then write() that buffer to the demux. Currently
this means copying, which seems fast enough even on lowly embedded
platforms, but an mmap() like method is on my TODO.

But meanwhile I think we should have general input devices and never
write to the demux directly. The the "frontend" vs. "other input"
naming issue will be resolved implicitely.

- drop enum dvb_dmx_source_type
- make DVB_DMX_SET_SOURCE work like DVB_VIDEO_SET_SOURCE

Maybe Florian wants to let us know about his ideas?

> 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.

see above

> 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?

For hw I know it is at a fixed position between demod and demux.


> 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%

We need that, but what about multi-PES filters? video PES packets are much
larger than audio, so giving the threshold in # pkts is not ideal.

> 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.).

I think applications should set it explicitely. Maybe we should even
make it a required parameter for the SET/ADD filter calls.

> 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?

That's an open issue. I was thinking about two possibilites:
- you must do a DMX_GET_EVENT directly after a read() to get information
  about possible events regarding the data you just read, i.e. "bytes"
  would point into the buffer last read(); this is ugly but might work
- don't use read() and DMX_GET_EVENT at all, but get data and associated
  events together via a DMX_GET_RECORD_DATA ioctl. One could use a
  design like v4l2 has where buffers are queued in advance, the data
  is DMAs directly into the buffers and the application is notified if a
  buffer is ready. The queue buffer pairs for data+events.

I would be interested to know if Zarlink hardware supports start-code
search for stream recording, and how the hw handles start-code found
events wrt the recorded data. Our hw puts events into a seperate ring
buffer in RAM and uses a 32bit packet count to point into the recorded
data. Packet count offsets for dropped packets has to be managed in sw.

Does anyone have a good idea how to design that recording event API?

> 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?

I tested with streams which had subtitles in the video and overlayed
the same subtitles via DVB-subtitles. The was a small delay of one
or two frames visible. I don't think that matters.

> 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?

I don't think that there's a substantial speed difference. Signals are
just a mess wrt multi-threading.

> 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.

I don't think it's important to have this, but I consider adding it.
What kepts me from doing it are the somplications for hw which has
two STCs but supports only one STC_CMP.

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

The demux descrambler is always on, always connected ;-)
You just set the key pairs into one of the available "slots", and
assign the slot number to the PID filter (i.e. more than one
PID can be descrambled using the same key pair).

- DVB_DMX_SET_PID_FILTER
- DVB_DMX_SET_DESCR_PID, chose any index (slot number)
- DVB_DMX_SET_DESCR_KEY odd/even according to ECMs

We should add a DVB_DMX_CAP_NUM_KEY_PAIRS.


Regards,
Johannes


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