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

[Rob.McConnell@Zarlink.Com]

Hi Johannes,



> Hi,

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

Yup, its been a busy day on the keyb, but I think we all have benefitted :
)

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

Nice one!

> > For audio h/w
> [snip]

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

Sounds like a good idea.  I can comment on AC-3 as I used to work on this
in my past life. The past always seems to creep up and bite you on the arse
again ; )


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

Yup, this sounds like a good idea.  Not sure how it would work if you had
h/w where you have a dma from the HDD to memory and then another dma from
memory to the demux device.  I guess this would be another discussion on
DMA.

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

See one of mail earlier mails for an example, please.

> > 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 explicitly. Maybe we should even
> make it a required parameter for the SET/ADD filter calls.

This sounds logical.  For example, you may want to setup a VIDEO PES filter
on PID xyz that goes straight to the video decoder h/w. You may also want
to setup a SUBTITLE PES stream on PID abc that goes into a circular buffer
in memory for a user-process to extract and decode. Having the type of
filter, PID and output type all wrapped up in the "dvb_dmx_pid_filter"
structure makes sense.

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

Can't really comment on this yet - sorry ; )

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

OK, that sounds fine.

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

Agreed.

> > 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 kept me from doing it are the complications for hw which has
> two STCs but supports only one STC_CMP.

That's just badly designed h/w : )

Thanks Again,

Rob : )






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