[linux-dvb] Re: LinuxDVB V4 API questions (3)

[Michael Hunold <hunold@convergence.de>]

Hello,

On 04/07/04 12:55, Alasdair FARMER wrote:

> 1)  I have a concern from a robustness perspective about
> the way in which connections between demux's and decoders
> is handled.  If we assume that we have a demux feeding a
> decoder, through a mmapped buffer.  What happens if the file
> handle on the demux/filter is closed ?

Most likely you'll have vmalloc()ed or kmalloc()ed kernel memory for 
your buffer memory for each instance of your "memory input". This memory 
is per memory-device, not per open.

So if somebody closes the device, simply stop the decoder from further 
reading. That's all.

> As I understand it 
> this will result in the buffer 'disappearing' as it is
> allocated/freed by the demux for the filter on that instance.

Yes. Because nobody is providing data any more, the decoder will stop 
anyway.

> BUT what about the decoder - this could still be trying to
> decode from the buffer in ignorance that the buffer is no
> longer there/valid...

You need to make sure that you don't release any buffers that might be 
in use.

> True, it would be possible for the
> decoder to check the file handle on every operation - but
> this is overhead you really do not want.  I would like to
> see some kind of back linking to allow the demux to tell the
> decoder that it is closing down.  I realise this is mainly a
> robustness issue - but one I think worth implementing.

It depends if you want to use a push or a pull model. If the decoder is 
pulling the data from the buffers, you can set a flag after closing that 
tells the decoder "this buffer has been invalidated, please stop now". 
If you are pushing the data to the decoder, then you can simply tell him 
to stop when a user closes the file.

This depends how you implement your driver. Of course the behaviour 
needs to be specified in the API documentation (which I'm looking 
forward to begin next week).

> 2)  With regard to playback of recordings I am unclear how
> this will work in the new model...  If a recorded stream were
> being written to a demux then which instance (given that the handle
> is actually to a filter rather than a demux itself).  I am not
> convinced that a memory frontend is the correct or best solution.
>  The semantic model I am working with is that the frontend is
> providing a transport stream to a demux which is filtering and
> passing the appropriate sub streams on to a decoder/storage.
> The frontend is responsible for presenting a single transport
> stream to the demux, dealing with any issues of source or routing.
> I would actually like to see a write interface on the frontend so
> that a recorded stream could be written to a frontend (rather than
> the stream come from a tuner).  This neatly maintains a consisten
> t model and removes some complexity at demux level.  In our scenarios,
> it is not actually possible to 'write' to a demux anyway, a recorded
> stream would have to be feed back into what is essentially a frontend
> - so for our hardware solutions, we would need a write api on a
> frontend anyway.  This also simplifies CA considerations.

Yes, I agree. I've started working on a "memory input" interface today, 
where you can open a "memory0" device and mmap() a "playback 
ringbuffer". You can then write to the mmap()ed ringbuffer buffer and 
confirm data areas to the driver. The underlying hardware can then dma 
from this memory to the demux for example. I made sure that the hardware 
I know can work with this model.

> Regards
> Ali Farmer.
CU
Michael.


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