On Fri, 05 Dec 2003 15:45:09 +0100 Holger Waechtler <[EMAIL PROTECTED]> wrote:
> > a) is very easily solved; I just tried to comment the > > TS_PAYLOAD_ONLY flag around line 657 of dmxdev.c and > > the packets are not modified anymore. A new flag > > will be enough (sadly, the obvious name "DMX_OUT_TS_TAP" is > > already taken by dvrY and renaming it to "DMX_OUT_TS_TAP_DVR" > > would break source code compatibility). > > If you invent a good flag name I think this change would be ok as > extension in V3, it can easily get checked by applications - they just > need to look whether the new flag is defined. Is DMX_OUT_TAP_188 good enough? > > b) needs a deeper change, because we have to remove the > > assumption that "one filter (pid) per open file". I think > > it can be done with the introduction of a list of filters > > and ioctls to add/remove filters (instead of just "set"). > > We should postpone this, such a change is hard to implement when we need > to maintain API compatibility. Hard but not impossible. We currently have DMX_SET_FILTER and DMX_SET_PES_FILTER (hmm, another case of data recording implemented in a second time). The current behaviour is that one of those will set the filter of the involved file descriptor, replacing an existing filter. I would extend it by introducing a new flag for dmx_pes_filter_params, called, let's say, DMX_OVERLOAD or, maybe, DMX_APPEND or DMX_STACK. If this bit is set the existing filter (well, existing filters) are not replaced. Simply a new PID is added. For simplicity, dmx_input_t input and dmx_output_t output are checked to be the same as in the first filter and (not sure about it) dms_pes_type_t pes_type is checked to be DMX_PES_OTHER. If some condition is not verified then the operation fails, and with failure I refer to the replacement taking place despite of the flag. This extension would be perfectly compatible to old apps. API issues solved, a good implementation is doable IMHO. > > At that point dvrY is totally useless and it could be theorically > > removed (but it's better to not break existing apps, of course). > > We should keep it in v3, in v4 it will vanish anyways. The DVR device is > still required for MultiPID-TS filters when we don't implement b). I saw that v4 has "recordind filters" that are more or less what I'm trying to do. Is dvr totally redundant in v4? (read about what I said in a previous reply about one program setting pids, another reading packets). > > I could try to hack the code myself, but maybe someone else > > with more knowledge of the dmx_core internals can do it more > > easily than me. > > :) no - code should always get implemented by the one who needs it... Hehe :-) I tried. I'd continue with ...under the guide of the ones who know the environment better than him -- Roberto Ragusa r.ragusa at libero.it -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
