Felix Domke wrote:
> Johannes Stezenbach wrote:
> > Felix Domke wrote:
> >>linux/drivers/media/dvb/dvb-core/dmxdev.c:
> >>@@ -643,7 +643,11 @@ static int dvb_dmxdev_filter_start(struc
> >> ts_type |= TS_PACKET;
> >>
> >> if (otype == DMX_OUT_TAP)
> >>- ts_type |= TS_PAYLOAD_ONLY|TS_PACKET;
> >>+ {
> >>+ ts_type |= TS_PACKET;
> >>+ if (ts_pes == DMX_TAP_PES)/*i.e. DMX_PES_OTHER*/
> > I'm a bit confused, but I guess this should be:
> > + if (ts_pes != DMX_TAP_TS)
> >>+ ts_type |= TS_PAYLOAD_ONLY;
> >>+ }
>
> When doing a TAP filter (otype == DMX_OUT_TAP), ts_pes (aka. pes_type or
> tap_type) should currently be always equal DMX_PES_OTHER, as the other
> values only make sense with DMX_OUT_DECODER. (or am i wrong here?)
>
> My patch would add the possibility to use DMX_TAP_TS instead of
> DMX_PES_OTHER (or DMX_TAP_PES, which is the same value).
>
> Essentially, your code does the same, the only difference is when called
> with ts_pes being any DMX_PES_VIDEO/AUDIO/PCR but otype !=
> DMX_OUT_DECODER, which is invalid in my eyes.
>
> I could miss something here, though.
I already said I am confused ;-/. I would need to meditate over that.
> > I'm pondering if it would not be better to add the full
> > recording filter API from v4. OTOH, v4 rec filters are
> > somewhat overfeatured and complicated, and the public
> > PCI/USB drivers would not really benefit from the additional
> > features because of missing hardware, so maybe your propsal
> > is better. I need to sleep over this...
> We should implement something which doesn't require the (available)
> hardware drivers to change, in my view. Otherwise we risk the same fate
> as v4.
>
> Is this possible with the v4 rec filters, maybe with limited features?
I think the v4 rec filters can be implemented without driver support.
But it's a lot of work. The advantage is that the mmap() stuff avoids
one copy of the data (currently data is copied from hardware ring buffer
to filter device ring buffer, and then copied a second time during
read()). With special driver support one could even mmap() hw ring
buffer directly and save all copying (of course the hardware needs to
support this, none of the PCI/USB adapters do).
I am still unsure if it is worth it, though. It depends on
who implements it, I guess, and if someone expresses some
interest in it. Maybe we should keep it simple and go with your
proposal.
Johannes
