[linux-dvb] Re: V4 API proposal

["Haber, Thomas" <THaber@tee.toshiba.de>]

Hi Florian,


Florian Schirmer wrote:
> Hi,
> 
> >The number of demux devices should depend on 
> >how many input streams can be handled in parallel.
> 
> Right. But even then you can end up in a situation where 2 
> users try to set
> 2 demuxes into memory reading mode, but only one memory channel is
> supported. In this case the driver is allowed to simply 
> reject the second
> DMX_SET_SOURCE call with -EBUSY. If your hardware has 3 
> inputs but can only
> use 2 of them concurrently it doesn't make any sense to 
> provide 3 logical
> demuxes. Thanks for outlining this. I will change the proposal.

Correct, hardware dependencies are their in any case.

> 
> >I agree that this is a much better approach than using the 
> dvr. But please 
> >consider that when doing this we will get a functiuonality 
> that is not 
> >demultiplexing. Instead its somehow TS filtering and here we may need
> additional 
> >functionality that does not fit into the demux. The partial 
> output stream
> can 
> >consist one or more programs. We also need the filter some tables to 
> >get the stream information when doing playback. To have a 
> consistent TS
> stream 
> >we need to change the PAT and reinsert it into the stream.
> 
> I agree that this is more than just demultiplexing. But this 
> is what most of
> the hardware is capable of. IMHO playing around with the PAT 
> or any other
> information does not belong into the (kernel) demux device. 
> It's up to the
> (userspace) application or a (userspace) middleware library 
> to provide such
> services (e.g. PAT reinsertion). The STB's i'm aware of can 
> handle these
> "broken" PAT's by dooing some bookkeeping about the recorded stream.
> 

I agree.

> >Concerning PS and multiple PES, it also needs to be demuxed. 
> We also need
> to set 
> >filters based on the streamids, we have timing information 
> similar to STC,
> and 
> >we also have data that corresponds to tables.  When this is 
> in the same
> device 
> >the interface will get differnt meanings. If not we will get 
> a TsDemux and
> a PsDemux.
> 
> I agree that you may need some sort of demuxing here too. But 
> it's is very
> different from the demuxing done to the TS data. So you wont 
> get any benefit
> from merging the PS demux into the TS demux. That is why i 
> propose to create
> an additional device for that. (Even if the driver ends up 
> using the same
> hardware as the TS demux would do).
> 
> Thanks a lot for your comments.
> 
> Bye,
>    Florian

I can live with both situations. A reason for having seperate device 
is that we don't find a straight interface that is suitable for
both streamtypes. But if this is possible, and it makes sense, than 
i don't see a reason why not putting them into one. 
That the implementations are differnt is not important.
At the end it shall demultiplex a media stream.
Do you agree ?


Regards,

thomas    


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