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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
