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'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?
Felix
