Hi Johannes,
> Hi, > lots of questions, so it takes some time for me to go through them, > but they are highly appreciated! Yup, its been a busy day on the keyb, but I think we all have benefitted : ) > See my other posting. Current software uses on fd per PID, so it doesn't > matter. IMHO it matters only for stream recording. But I note your and > Ralphs preference, so I guess I'll go with ADD/DEL. Nice one! > > For audio h/w > [snip] > I'll start a new thread for that to separate it from the demux > discussion. Sounds like a good idea. I can comment on AC-3 as I used to work on this in my past life. The past always seems to creep up and bite you on the arse again ; ) > > *** Now for the new Q's: *** > > > > A. If we want to route a TS/PS/PES off a DVD or HDD through a PID filter, > > then I guess we would have to setup the source type of the filter to be > > "DVB_DMX_SOURCE_FRONTEND" with the correct "frontend_num". The same goes > > for an input from an external C/A modules or LVDS, etc. Is this the > > intention? Does the term "front-end" really make sense? > My thinking was to use DVB_DMX_SOURCE_MEMORY, because we use the > usual Linux file systems. We read() from a TS file into some > buffer in memory, then write() that buffer to the demux. Currently > this means copying, which seems fast enough even on lowly embedded > platforms, but an mmap() like method is on my TODO. Yup, this sounds like a good idea. Not sure how it would work if you had h/w where you have a dma from the HDD to memory and then another dma from memory to the demux device. I guess this would be another discussion on DMA. > > D. If h/w can generate an interrupt when we have received a full packet > > (PES level filtering) or when a certain number of bytes have been > > delivered, how does the API allow this threshold to be set? For example, > > should we have an API ioctl similar to the DVB_DMX_SET_BUFFER_SIZE ioctl to > > allow a threshold to be set before the h/w or s/w filtering should call the > > cb function? > > > > e.g. DVB_DMX_SET_BUF_THRESH 0 = none, 1 = one packet, 2 = two packets, > > .... 65535 = max packets. > > > > OR what about taking a percentage of the buffer size > > > > e.g. DVB_DMX_SET_BUF_THRESH 0 = none, 1 = one packet, 2 = 25% , 3 = 50%, > > 4 = 75%, 5 = 100% > We need that, but what about multi-PES filters? video PES packets are much > larger than audio, so giving the threshold in # pkts is not ideal. See one of mail earlier mails for an example, please. > > Also, the filter type such as SUBTITLE or VIDEO would be useful to know how > > to handle the data (buffer size, c/b function, etc.). > I think applications should set it explicitly. Maybe we should even > make it a required parameter for the SET/ADD filter calls. This sounds logical. For example, you may want to setup a VIDEO PES filter on PID xyz that goes straight to the video decoder h/w. You may also want to setup a SUBTITLE PES stream on PID abc that goes into a circular buffer in memory for a user-process to extract and decode. Having the type of filter, PID and output type all wrapped up in the "dvb_dmx_pid_filter" structure makes sense. > I would be interested to know if Zarlink hardware supports start-code > search for stream recording, and how the hw handles start-code found > events wrt the recorded data. Our hw puts events into a separate ring > buffer in RAM and uses a 32bit packet count to point into the recorded > data. Packet count offsets for dropped packets has to be managed in sw. Can't really comment on this yet - sorry ; ) > I tested with streams which had subtitles in the video and overlayed > the same subtitles via DVB-subtitles. The was a small delay of one > or two frames visible. I don't think that matters. OK, that sounds fine. > > If h/w had an STC compare interrupt in which a "DVB_DMX_SET_STC_CMP" ioctl > > would set a register that was automatically compared with the STC, then you > > would still have the problem of notifying the user-level process that the > > STC compare event occurred. Which is quicker, sending a process a signal > > (e.g. SIGUSR1) or having the process wait for an event to occur? > I don't think that there's a substantial speed difference. Signals are > just a mess wrt multi-threading. Agreed. > > Would it make sense to have the ability to have a DVB_DMX_SET_STC_CMP ioctl > > for h/w that uses it? For h/w that didn't support it, you could stick with > > user-level timers. > I don't think it's important to have this, but I consider adding it. > What kept me from doing it are the complications for hw which has > two STCs but supports only one STC_CMP. That's just badly designed h/w : ) Thanks Again, Rob : ) -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
