[linux-dvb] Record Filters in V4 API

[Rob.McConnell@Zarlink.Com]

Hi ML,

I have had to send this message again to the list.  This is the 2nd time
this has happened recently - any ideas why my messages don't seem to be
getting through?

Anyway with regards to Q5, I understand that the log is a log of events
that are stored in a separate area - correct?  I guess the idea here is to
allow quick navigation of the recorded data by reading the log to find an
event, and "jumping" to the actual stored data.  Please feel free to
elaborate on this or correct me.

Thanks,

Rob : )

----- Forwarded by Rob McConnell/Zarlink on 05/04/04 15:50 -----
                                                                                                                                 
                      Rob McConnell                                                                                              
                                               To:       linux-dvb@linuxtv.org                                                   
                      02-Apr-2004 06:49        cc:                                                                               
                      PM                       Subject:  Record Filters in V4 API                                                
                                                                                                                                 
                                                                                                                                 



Hi Again,

I have a few Q's regarding the functionality of the record filters for the
V4 API.

Q1: What are the meaning/functions of the record types?  For example, what
is the difference between simple read and a buffer based read?

Q2:  Some h/w I know has a register that has bit positions for each PID
filter "slot" so that many PID filter outputs can be "gathered" together
for recording purposes (all outputs DMA to a common area of memory).  In
this case, it is assumed that the PID filter slot(s) has/have already been
setup with the required filtering specification (e.g. PID, flags).
Presumably, the "add recording pids" ioctl would simply map down to setting
up this register?

What happens if a PID filter "slot" has not already been allocated and
setup?  Is there any mapping between what PID filter "slots" in the h/w
have already been setup and what record "pids" are required so as to return
an error?  You could have the case where you want to record the audio,
video and PCR pids of say BBC1, but you forgot to setup them up beforehand.

Q3: There are also devices that do not have any special recording h/w.  In
this case, would the "add recording pids" ioctl require that the PID
filter(s) has/have already been setup (using the DVB_DMX_SET_PID_FILTER
ioctl), or would that ioctl actually allocate and setup the necessary PID
filters?

Q4: Is the intention to directly copy each h/w PID filter buffer to a
common circular buffer in which a process can read or will you copy the
contents of each h/w buffer to a kernel buffer first before performing a
synchronised copy to a common circular buffer?  What sets up the size of
this common circular buffer anyway?

Q5:  The ioctl "DVB_DMX_RETRIEVE_RECORDING_DATA" returns a
"dvb_dmx_recording_data" struct, but what are the meaning of the
rec_offset/rec_len and log_off/log_len?  Is log shorthand for a log fs, or
is it pertaining to metadata that is stored separately to the actual
recorded A/V data?

How should this ioctl be used in conjunction with the read syscall on this
fd?  Do you issue this ioctl first to see how much data is available before
reading?

That's all for now.

Rob : )




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