> [EMAIL PROTECTED] wrote:
> >
> > > Unfortunately, if you do MHP or the like you will find that some
> > > Xlets (MHP applications) use more than 32 filters and will just
> > > fail if they don't get what they want...
> >
> > > Ultimately the user must be able to decide, if he wants all filter
[EMAIL PROTECTED] wrote:
>
> > Unfortunately, if you do MHP or the like you will find that some
> > Xlets (MHP applications) use more than 32 filters and will just
> > fail if they don't get what they want...
>
> > Ultimately the user must be able to decide, if he wants all filters
> > for one ch
Hi Holger and Co
> >>[EMAIL PROTECTED] wrote:
> >>
> >>>Having the ability to select the delivery format (parallel or serial)
> >
> > of
> >
> >>>the TS/PS to a potential input/selector device would be useful. I
guess
> >>>this would be an ioctl on the front-end device. That's one ioctl fo
Hi Johannes,
> [EMAIL PROTECTED] wrote:
> >
> > I agree that in the field, you would only have a fixed input (parallel
or
> > serial), but because we are using development boards that test every
aspect
> > of the silicon, we do require this functionality (typical h/w bods).
Also,
> > when provi
[EMAIL PROTECTED] wrote:
>
> I agree that in the field, you would only have a fixed input (parallel or
> serial), but because we are using development boards that test every aspect
> of the silicon, we do require this functionality (typical h/w bods). Also,
> when providing software to 3rd partie
[EMAIL PROTECTED] wrote:
Hi All,
[EMAIL PROTECTED] wrote:
Having the ability to select the delivery format (parallel or serial)
of
the TS/PS to a potential input/selector device would be useful. I guess
this would be an ioctl on the front-end device. That's one ioctl for
the
front-end device
Hi All,
> [EMAIL PROTECTED] wrote:
> >
> > Having the ability to select the delivery format (parallel or serial)
of
> > the TS/PS to a potential input/selector device would be useful. I guess
> > this would be an ioctl on the front-end device. That's one ioctl for
the
> > front-end device API.
[EMAIL PROTECTED] wrote:
>
> Having the ability to select the delivery format (parallel or serial) of
> the TS/PS to a potential input/selector device would be useful. I guess
> this would be an ioctl on the front-end device. That's one ioctl for the
> front-end device API : )
Why would this
Hi Folks,
I have finally had some time to have a look at your proposal Michael and
think it is better than what we have at the moment. It certainly seems to
fit the hardware requirements from our end, so I will comment appropriately
below. Please accept my apologies for a long email this is g
Michael Hunold wrote:
Hello Holger,
Different demux devices with included filter capabilities suggest to
the user that there's hardware behind it. This is currently not the
case for any hardware out there.
It is. Whenever we implemented multiple demux devices for an adapter
each of them stand
Michael Hunold wrote:
Hello Holger,
I'd really like to know what stuff is not covered by my approach and
why you think it's too high level.
It makes abstractions that don't match any hardware I know. I don't
know any hardware that has real stream filters in the decoder units.
But some hardwa
Michael Hunold wrote:
>
> I don't want to get rid of the "demux" devices, I just think that the
> filters shouldn't be a part of them. Again: if the user has multiple
> demuxes and can set multiple PID filters, he might think that these
> filters are part of the demux. And this isn't the case f
Hello Holger,
Different demux devices with included filter capabilities suggest to
the user that there's hardware behind it. This is currently not the
case for any hardware out there.
It is. Whenever we implemented multiple demux devices for an adapter
each of them stands for an independent de
Hello Holger,
I'd really like to know what stuff is not covered by my approach and
why you think it's too high level.
It makes abstractions that don't match any hardware I know. I don't know
any hardware that has real stream filters in the decoder units.
But some hardware has specialized filter
oh-ough, I should write my mails slower: s/\/here/g,
s/\/allocate/g. Hope that was all. sorry.
Holger Waechtler wrote:
Michael Hunold wrote:
In theory, you can write to user space memory from device drivers
easily. In practise, most hardware has some sort of DMA limitations
(for example 16k al
one more remark that came to my mind:
Holger Waechtler wrote:
Michael Hunold wrote:
But before thinking about this, someone should really investigate if
these memcpy()s are *really* a problem for system performance. Sure,
there is a lot of copying going on, but I guess that most of the
*real*
Michael Hunold wrote:
In theory, you can write to user space memory from device drivers
easily. In practise, most hardware has some sort of DMA limitations (for
example 16k aligned memory), so this is not an option unfortunately,
because you cannot control memory allocation for userspace.
even i
Ralph Metzler wrote:
Holger Waechtler writes:
> If we want to remove even more ambinguities we should distinguish in the
> demux API between general purpose filter banks and decoder-attached
> filter banks.
>
> Maybe this would even simplify using the API since the routing might get
> m
Hello Ralph,
> I like the idea of a source based routing in Michael's approach (we've
> been discussing this issue before in another thread some months ago),
> the idea not to specify input and output device of the demux but instead
> specify a stream source in the decoder. This removes som
Michael Hunold wrote:
Hello Holger,
I like the idea of a source based routing in Michael's approach (we've
been discussing this issue before in another thread some months ago),
the idea not to specify input and output device of the demux but
instead specify a stream source in the decoder. This
Michael Hunold wrote:
Please refer to the fundamental difference I desribed in my mail to Ralph:
Different demux devices with included filter capabilities suggest to the
user that there's hardware behind it. This is currently not the case for
any hardware out there.
It is. Whenever we implemente
Hello Holger,
I like the idea of a source based routing in Michael's approach (we've
been discussing this issue before in another thread some months ago),
the idea not to specify input and output device of the demux but instead
specify a stream source in the decoder. This removes some ambingiut
Hello Johannes,
> Ralph wrote:
Again, this depends on the hardware.
The current API V4 proposition basically treats each filter as if it
is a streaming device. For software filters this is no problem except
that DMA is probably out of the question. Some hardware only has two
recording devices whi
Hello Ralph,
> - specialized APID/VPID/PCR filters for each mpeg decoder (so they
> technically belong to the mpeg demux/decoder, not to the other demux
> devices)
But they do (I guess you are talking about NEC hardware?!).
Might be. ;-)
They have to be assigned to one of the demuxes and th
> >Why can't demuxing just be attached wherever you like. Playback, record,
> >like a push down stack : sys v streams.
>
> can you please explain a bit more in detail what you mean?
Only just throwing an idea out here. Michael has a more specific
feel for the problems and solutions.
The system v
Holger Waechtler writes:
> I'm not aware of any chipset without a dedicated demultiplexer unit, are
> you?
> (just to get the convention clear: The Demultiplexer seperates a
> multiplexed - a concatenated stream of packets with different packet IDs
> - and routes the packets to the destinat
Ralph Metzler wrote:
> Michael Hunold writes:
> >
> > This is implicit behaviour and therefore bad design. There is only one
> > mpeg decoder, so there is only one set of PIDs that can be set. Because
> > of this, there should be one specialized "mpeg demux".
>
> While I do not agree that t
Jamie Honan wrote:
But video/audio/pcr for example has nothing to do with demuxing, it's
mpeg decoding. Section filters are always bound to one PID, so why not
one oper per PID?
video, audio and pcr _do_ have something to do with demuxing, see above.
Being naive, I can ask stupid questions :)
Ralph Metzler wrote:
Michael Hunold writes:
> > Therefore they don't know what a PID is. So why should the
> > A/V PIDs be given to the mpeg decoder device? The Transport Demux has to
> > know them, so it can deliver the demultiplexed data to the decoder.
>
> The more advanced hardware I know
Michael Hunold writes:
> > Therefore they don't know what a PID is. So why should the
> > A/V PIDs be given to the mpeg decoder device? The Transport Demux has to
> > know them, so it can deliver the demultiplexed data to the decoder.
>
> The more advanced hardware I know has a design like th
Hello Jamie,
please have a look at my other mail for details.
Mpeg decoders usually don't parse Transport Streams (I only know one old
chipset which has some kind of simple demultiplexer built in for single
program TS). Therefore they don't know what a PID is. So why should the
A/V PIDs be given
Hello Andreas,
++
| MPEG Decoder 0 |
to demux <-- ++
| APID|VPID|PCR |
+-
Mpeg decoders usually don't parse Transport Streams (I only know one old
chipset which has some kind of simple demul
> Mpeg decoders usually don't parse Transport Streams (I only know one old
> chipset which has some kind of simple demultiplexer built in for single
> program TS). Therefore they don't know what a PID is. So why should the
> A/V PIDs be given to the mpeg decoder device? The Transport Demux has to
On Thu, 2003-10-09 at 21:11, Michael Hunold wrote:
>++
>| MPEG Decoder 0 |
> to demux <-- ++
>| APID|VPID|PCR |
>+-
Mpeg decoders usually don't parse Transport Streams (I only know one
34 matches
Mail list logo
