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