[linux-dvb] Re: V4 API Implementation Q's

[Michael Hunold <hunold@convergence.de>]

Hello Rob,

> OK, from our discussions it sounds like it will be the responsibility of
> the code "underneath" the API to control the resources.  We just specify
> the max number of *h/w* filters of each type - right?  e.g. If you don't
> have dedicated record h/w then you should set the
> DVB_DMX_CAP_NUM_RECORDING_FILTERS to 0 - correct?
Correct. Or you fake a recording hardware by using "sw-recording.c" and 
set up the recording filters using ordinary pid filters. This is how the 
av7110 driver works -- all data is copied from the irq handler to the 
recording ringbuffer.

> From what I can see, the AV7110 h/w automagically returns a handle to a new
> feed with an error returned if no more resources are available, so the h/w
> takes care of resources directly - right?  
Right.

> For other h/w that does not
> behave like this (stuff I'm working on), you would require a conceptual
> filter slot array where you may have 32 pid filter slots N audio decoder
> slots and M video decoder slots.  You would then have to manage the
> allocation/deallocation and setting up of filters from the set feed/filter
> ioctl - is this correct?
I don't see why this is different. If the user requests a certain 
filter, you can look at your slot array and pick a free slot, or not?

> Ok, another Q is regards to how the record filter adding/deletion mechanism
> works.  I asked this Q b4 in a previous email, but didn't get a reply
> (sorry if you haven't had a chance to comment).  The Q went on the lines of
> does the add pid ioctl for the record filter actually go and try to
> allocate a pid filter if one isn't already running (effectively implement
> the DVB_DMX_SET_PID_FILTER ioctl)?
This is higly hardware dependent. If your hardware only has pid 
filters,that cannot write into one common memory buffer, then you cannot 
provide "real" recording filters.

You can of course fake a recording filter again by creating a separate 
recording buffer memory, where the data from the indivudal pid filters 
is written to (like the av7110 does).

> Also, for h/w that doesn't have dedicated record h/w, would the output of
> each pid filter be directed to a common ringbuffer with a single copy or
> would you have a 2 copy approach - one from the h/w buffer to a kernel
> buffer and the 2nd from the kernel buffer to the common ringbuffer?  I
> would guess the later, as you may want to setup some normal pid filters
> first and then decide to setup a record in parallel as well.
Some hardware has PID filters that can write to one common memory, so 
implementing recording filters is easy. I admit that using "normal" pid 
filters on the same PID isn't going to work on most hardware, although 
passing the same PID to a hw decoder works for most. This is a common 
restriction that applications need to handle accordingly.

But there is hardware out there that lets you do everything in parallel: 
recording PID x, use a pid filter on PID x and send PID x to a hw decoder.

> The record filter is a bit of pain in terms of nomenclature and
> implementation.  I know 2 types of h/w that operate in 2 different ways.
This is hard to follow and understand without the actual hw 
specifications. 8-(

> Finally, what are the meaning of the newly added record methods in the
> filter bank:
> try_add_recording_pid
> commit_recording_pid
> confirm_recording_data
> etc.
try_add_recording_pid)
try_del_recording_pid)
commit_recording_pid)
release_recording_pid)

Because of the fact that all operations need to be atomic, it must be 
possible to try to add or try to del recording pids, whithout actually 
adding or deleting it. Assume that a user wants to add 3 recording pids, 
but only 2 filters are available. You'll first try to add them, but 
after the third pid you'll notice that it doesn't work. In that case you 
 call release_recorind_pid() for the first 2 PIDS and the previously 
allocated filters will not be used at all.

retrieve_recording_data() and confirm_recording_data() directly map onto 
the DVB_DEMUX_RETRIEVE_RECORDING_DATA and 
DVB_DEMUX_CONFIRM_RECORDING_DATA ioctls. The hand out an area of the 
recording memory buffer to userspace, so the data can be processed or 
written to disk. "test_recf" is a sample program that shows the usage.

> TIA,
> Rob : )
CU
Michael.


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