Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: DVB API questions



Florian Schirmer wrote:
> Hi,
> 
> can someone elaborate on this issues? 
> 
> Question 1:
> 
> DMX_PES_TYPE_{VIDEO,AUDIO,PCR,TELETEXT} have a special meaning. Allright. But
> how to handle the case if someone requests e.g. VIDEO and does not request
> OUT_DECODER at the same time.
> 
> Do i have to treat the type as DMX_PES_TYPE_OTHER? Is there any special case 
> to worry about? I've asked Holger about this. And he told me that using 
> DMX_PES_TYPE_{VIDEO/AUDIO}+DMX_PES_TYPE_OTHER at the same time will result in 
> a delivery of this stream(s) to the vdr device.

Only if you route the stream to the dvr device using 
filter.output=DMX_OUT_TS_TAP.


> Maybe at least ;-) Anything i 
> need to care of?
> 
> What about DMX_PES_TYPE_{PCR,TELETEXT} and not selecting OUT_DECODER?

Then you get the PES packets to memory if you select 
filter.output=DMX_OUT_TAP or to the dvr device if you select 
filter.output=DMX_OUT_TS_TAP.


> Question / Proposal 2:
> 
> As requested before: OUT_DECODER should be a selectable flag. At the kernel 
> side it is. But not at the userspace interface.

Here you are right. (This is one of the API changes I was asking for). 
I'll modify dmx_output_t so that it defines a bitfield, unfortunally 
this breaks again binary compability, so you'll have to compile all your 
DVB software again...


> Problem: If OUT_DECODER is selected the user has no way to select the format 
> the dmx delivers the data to the decoder. This can cause trouble if a user 
> wants to see and record a stream. See question 5.

I don't see a problem here, if the user reads from the 
/dev/dvb/adapter0/demux0 he will get PES packets, if he reads from 
/dev/dvb/adapter0/dvr0 he will get TS packets.


> Question 3:
> 
> Some dmx'es (at least our) are not capable of delivering the same pid into two 
> or more feeds at the same time. So this will end into problems if two users 
> try to catch the same pid.
> 
> Does the API handle this case internally or do i as a kernel developer need to 
> care about it? 

Hmm, here I'm not sure about the answer - I don't know this part of the 
driver very well. Could you please read the source and try to find this 
out? If the dvb-core can't handle multiple clients on the same PID we 
should definitely introduce this...


> Proposal 4:
> 
> At present we will cycle all active feeds and check if there is a pid match 
> and deliver the data to all matching feeds. But it would be nice if the api 
> will handle that internally and just opens one feed even if there are two or 
> more users (on the same pid).

Maybe Ralph or Marcus can answer how this was intended to be handled?

In my opinion you are right and the core should set only the required 
feeds and copy data into multiple client (ring-?) buffers if necessairy.


> Question 5:
> 
> What happens if the first user requests PES (feed will deliver PES) and the 
> secord wants to have plain TS? API handles that? API refuses that? Developer 
> has to care?

Then you feed TS packets into the Software demultiplexer and the 
dvb-core cares about the rest.

Well, it should do so if there are no hidden bugs...

Holger



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index