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

[Rob.McConnell@Zarlink.Com]

> Rob.McConnell@Zarlink.Com wrote:
> >
> > 1. Open up an fd on the demux device and use the DVB_DMX_ADD_PID_FILTER
> > ioctl passing in the PIDs of the video,audio and subtitle streams of
BBC1.
> > Immediately the PID filters will be activated and start filtering data
to
> > the h/w buffers.  In this instance, the DVB_DMX_SET_PID_FILTER ioctl
isn't
> > used, but we should still have it to cater for individual streams on
> > individual fds. Right?

> DVB_DMX_SET_PID_FILTER will always have to be used for setting
> output_format. But see my other Mail.

Agreed.  You would always have a TS or PES output format global to the fd
in question.

> > Q: What about BBC2 data left in the circular buffer after the
> > DVB_DMX_DEL_PID_FILTER is issued?  We can't flush the global circular
> > buffer otherwise we lose the data relevant to BBC1.  Should the
> > DVB_DMX_DEL_PID_FILTER then wait until all the data in the buffer is
> > consumed before actually stopping/removing the filter?

> No. If you have a single threaded program there would be no way to
> consume the data if DEL would wait (unless it is consumed inside
> the driver).

It's a tricky one.  Inside the driver would mean keeping track of the data
interleaved in the circular buffer along with the data from the other
channel being recorded.  Having to "chug" through this buffer discarding
the data sounds a bit of a 'mare. I guess it would be easy to just leave
the data in the buffer (only small buffer anyway) and let the new recording
pick it up.  The software could always blanks/mute the first 100ms of
content to ensure that there is a smooth transition.

> Can you have a look at the filter flags and tell me if your requirements
> are met there, too?

Ok, let's have a look...

#define DVB_DMX_OUT_MEMORY
All PID filters attached to the fd would need this set.

#define DVB_DMX_FULL_TS
OK for h/w that can handle this.

#define DVB_DMX_EVENT_LOGGING
Event logging on an individual PID filter not an fd would be more flexible,
unless the ioctl returns the PID associated with the event(s).

#define DVB_DMX_WAIT_FOR_PUSI
Yes please. This should be relevant to filter not fd.

#define DVB_DMX_OUT_DUPES
This would be an option to allow or disallow duplicate packets (with the
same PID and continuity counter).  This would be a global option on an fd I
believe. This is available in h/w on some chips.

#define DVB_DMX_OUT_ERRPKTS
Another global option (i.e. on an fd) to allow packets with error(s)
through to the h/w buffer. I would use this.

#define DVB_DMX_HIGH_PRIO_ONLY
#define DVB_DMX_LOW_PRIO_ONLY
This is dependent on the filter not the fd.  The Canal+ spec requires this,
and is an option on our h/w.

#define DVB_DMX_ADAP_FIELD  (or whatever we may want to define it as)
Some h/w allows only the TS header and adaptation field to be output to a
buffer.  This might be useful for private data filtering or retrieving the
random access indicator for determining when a video sequence header
starts. The h/w buffer would contain just the TS header and adaptation
fields.

As for the DMX_SET_EVENT_MASK and DMX_GET_EVENT ioctls (please prefix with
DVB_), these would have to be issued on a PID attached to an fd. Some
grouping of PID value to event would be needed.

That's all 4 now.

Rob :)






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