Hi,
On Tue, Feb 25, 2003 at 07:31:30PM +0100, I wrote:
> Ralph Metzler wrote:
> >
> > - Move the memory frontends to separate devices.
> > Either also call them frontend with type memory frontend
> > or call them memfrontend, mfrontend, dvrin, ... whatever
> > They should offer mmap, write,
Florian Schirmer wrote:
>
> >For point 4, the h/w that I am using does allow the capability to discard
> >all packets until the PUSI flag is found in a TS header (after which all
> >TS packets are matched). This feature just reduces the amount of packets to
> >handle/copy/parse etc. For h/w t
[EMAIL PROTECTED] wrote:
(I edited quoting for clarity)
> > 4) Whether to match TS packets with the payload unit start indicator
> > set (after which all packets would be matched).
>
> For point 4, the h/w that I am using does allow the capability to discard
> all packets until the PUSI fl
t;[EMAIL PROTECTED]cc: [EMAIL PROTECTED]
e> Subject: Re: [linux-dvb] Re:
On Tue, Feb 25, 2003 at 01:50:41PM +, [EMAIL PROTECTED] wrote:
>
> I was also having a look at the filter specs and I think we should have
> more flexibility for setting other criteria such as the following:
>
> 1) Whether to allow full TS packet or just payload through.
That's the fun
Ralph Metzler wrote:
Johannes Stezenbach writes:
> > - Move the memory frontends to separate devices.
> > Either also call them frontend with type memory frontend
> > or call them memfrontend, mfrontend, dvrin, ... whatever
> > They should offer mmap, write, etc. maybe even a software con
Johannes Stezenbach writes:
> > - Move the memory frontends to separate devices.
> > Either also call them frontend with type memory frontend
> > or call them memfrontend, mfrontend, dvrin, ... whatever
> > They should offer mmap, write, etc. maybe even a software controlled
> > rate c
Ralph Metzler wrote:
>
> What I propose is:
I'm afraid I have more questions than answers yet...
> - Move the memory frontends to separate devices.
> Either also call them frontend with type memory frontend
> or call them memfrontend, mfrontend, dvrin, ... whatever
> They should offer mma
.de> cc:
Sent by: Subject: [linux-dvb] Re: C/A routing
Question
[EMAIL PROTECTED] writes:
> I think I have come to the conclusion that having multiple demux devices in
> the system is the best option. In this case, each "virtual" demux device
> would still need a routing for the possible TS inputs (an IOCTL), but each
> PID filter wouldn't have to choose t
Johannes Stezenbach writes:
> Ralph Metzler wrote:
> > [EMAIL PROTECTED] writes:
> > > I agree that as more hardware with PVR capability is becoming available, we
> > > will have to consider different routing scenarios. The h/w that I am
> > > working on allows for parallel/serial TSs from
To: [EMAIL PROTECTED]
.de> cc:
Sent by: Subject: [linux
Ralph Metzler wrote:
> [EMAIL PROTECTED] writes:
> > I agree that as more hardware with PVR capability is becoming available, we
> > will have to consider different routing scenarios. The h/w that I am
> > working on allows for parallel/serial TSs from multiple sources as well as
> > from C/Is
On Mon, Feb 24, 2003 at 01:40:31PM +, [EMAIL PROTECTED] wrote:
>
> I agree that as more hardware with PVR capability is becoming available, we
> will have to consider different routing scenarios. The h/w that I am
> working on allows for parallel/serial TSs from multiple sources as well as
>
[EMAIL PROTECTED] writes:
> I agree that as more hardware with PVR capability is becoming available, we
> will have to consider different routing scenarios. The h/w that I am
> working on allows for parallel/serial TSs from multiple sources as well as
> from C/Is and from a HDD. Yes, in the H
e> Subject: [linux-dvb] Re: C/A routing
Question
Sent by:
[EMAIL PROTECTED] wrote:
>
> I've looked at the Demux API and had a quick look at the C/A but I don't
> see an apparent way in which to route a TS from a different source other
> that from the front-end to a C/A device. What I want to be able to do is
> route a TS from different front-ends and al
17 matches
Mail list logo
