Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Alternative v4 demux AP



Rob.McConnell@Zarlink.Com wrote:
> Johannes Stezenbach wrote:
> 
> > - add DVB_DMX_SET_DECODING_FILTER to drive the special "decoder filters";
> >   for hardware which has no special filters these would just use
> >   a GP filter
> 
> Good.  Would we want to issue a AUDIO/VIDEO/PCR filter setup in 1 ioctl, or
> would it be better to have individual ioctls for each of the streams?  What
> if you want to change just the audio PID for another audio language, for
> example?

I would change one PID per ioctl. The name "DVB_DMX_SET_DECODING_FILTER" is
a bit awkward, but it takes a pid_type parameter which is easily
extensible (e.g. if you have special hardware for teletext or maybe
even subtitle decoding).

> > - keep DVB_DMX_SET_PID_FILTER for GP filters only (one PID per fd,
> >   add DVB_DMX_PAYLOAD_ONLY and DVB_DMX_TS_HEADER_ONLY)
> 
> Good, this is also how I envisaged it as well.  Question, does
> DVB_DMX_TS_HEADER_ONLY provide both the header and adaptation fields?
> Should we add a separate DVB_DMX_TS_ADAP_FIELD flag as well for extracting
> private data or PCRs?

Popular hardware I know has no support for it, but it would be
easy to do in software.
Question: What do applications need?


> > - add DVB_DMX_SET_RECORDING_FILTER in conjunction with
> >   DVB_DMX_ADD/DEL_RECORDING_PID for special purpose recording filters;
> >   some hardware would just use GP filters internally; this
> >   would also get rid of the DVB_DMX_EVENT_LOGGING flag
> 
> So DVB_DMX_SET_RECORDING_FILTER would setup a single PID filter and
> DVB_DMX_ADD_RECORDING_PID/DVB_DMX_DEL_RECORDING_PID would add/del a single
> PID to/from the existing fd?
> 
> Then DVB_DMX_START/STOP would synchronise the group filtering - correct?

My thinking was:
- DVB_DMX_SET_RECORDING_FILTER does not set any PID, but just prepares
  the recording hardware
- ADD/DEL_RECORDING_PIDS (note the added a trailing S ;) take an array
  of PIDs and recording starts/stops immediately


> > If you want to record and decode a PID at the same time you would
> > need to open two fds to set the DECODING_FILTER and RECORDING_FILTER
> > for the same PID.
> 
> Note that not all h/w allows this capability.  You would need some way of
> preventing the recording filter to be setup when a decoding filter is
> active or vice versa.

We can use capabilities to make that clear. On some hardware it is only
possible to record while decoding if a second demux channel is used
(both channels connected to the same input).


> e.g. /dev/dvb/adapter0/demux0/pidfilter

I'll comment on this in a second Mail.


> Would you need to have the "dvb_dmx_output_format" struct included in the
> new "dvb_dmx_decoding_filter" as I don't know of any A/V decoders that can
> accept a TS packet input (only PES or ES)? Anyone know differently?

I think this will be handled internally in the driver. AFAIK many
decoders want to see the TS error_indicator for error concealment,
but ultimately need PES for decoding and sync. I don't know any
hardware where you could change the internal format used.

The DVB_DMX_PAYLOAD_ONLY flag for "normal" PID filters already
covers the PES vs. TS format issue.


Regards,
Johannes


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



Home | Main Index | Thread Index