[EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
