Johannes Stezenbach:
> What I meant to say is that we would probably want to have
> support for copying data within the kernel/driver, without
> having to copy data to userspace from one driver and back into
> the kernel to the other driver. E.g. VDR currently does a lot
> of copying in "transfer
On Wed, Mar 19, 2003 at 03:42:40PM +0100, Haber, Thomas wrote:
> Hi Johannes,
>
> i'm still not sure about it.
>
> > I've spent some time thinking about this. IMHO the most
> > "natural" approach
> > would be to use the demux file descriptor where you have set the
> > appropriate filters, e.g. f
On Fri, Mar 07, 2003 at 02:15:41PM +0100, Haber, Thomas wrote:
> Florian Schirmer wrote:
> > Thomas Haber wrote:
> > >The usage of DMX_GET_SOURCE & DMX_SET_SOURCE is suitable for connecting
> > >demux to frontend. But how to connect Audio to a Filter ?
> > >I propose to have a common mechanism for
Please discard my proposal. Everything could be done
from user space with user space fs and a full TS dump
card, no need for anything else in the API, I guess.
Emard
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
> No the OEM provides the tables. Have you ever used a digital
> receiver. Most of them come with preprogrammed transponder and channel
I Never got any STB receiver really.
> lists. Which are sometimes updated by a channel search by the user or
> a firmware update by the OEM.
I see.
> It may al
> > a) Not all hardware has the ability to provide a raw transport stream
> If it is impossilble, how does this STB hardware scan channels to
> search for stations?
You only need to look at the info PIDs (PAT SDT NIT, starts with
well known fixed PIDs) to get all the channels and other
transpond
[EMAIL PROTECTED] writes:
> >
> > This "autodetection" is technically impossible.
> > a) Not all hardware has the ability to provide a raw transport stream
> > b) If it had the capability, you would lose data between the time the
> > kernel creates the device and the user scans for directory
This "autodetection" is technically impossible.
a) Not all hardware has the ability to provide a raw transport stream
b) If it had the capability, you would lose data between the time the
kernel creates the device and the user scans for directory entries.
Think of tables which are broadcasted at v
On Thu, 2003-03-13 at 23:16, Emard wrote:
> For the media source device, I propose 2 devices:
> One is raw TS dump device. There you can always
> get raw dump directly as it is received by the
> vpeirq().
There is no vpeirq() in most drivers ;)
> Second device is not a single device, but a direc
> Then you click on one of the live icon pids to maximize
> the picture and hear the sound.
>
> Emard
In embedded application with specialized hardware
that has some hardware procession capabilities
and additional specialized bypass driver has to
be made.
Internal bypass driver will replace use
For the media source device, I propose 2 devices:
One is raw TS dump device. There you can always
get raw dump directly as it is received by the
vpeirq().
Second device is not a single device, but a directory
of many demuxed devices, dynamically created/removed
upon current TS autodetection (sc
On Thu, Mar 13, 2003 at 04:21:39PM +, Franck Arnaud wrote:
> Emard:
>
> > I would also suggest the global idea should be
> > to try to optimize the api for budget-type cards only,
> > and silently discard any onbard mpeg or hardware
> > demux as if we already had mpeg2 decoder and descrambler
Emard:
> I would also suggest the global idea should be
> to try to optimize the api for budget-type cards only,
> and silently discard any onbard mpeg or hardware
> demux as if we already had mpeg2 decoder and descrambler
> in open source either in the kernel or as external application.
Could i
I think you misunderstood something. One major goal is to use the dvb
api in many set top boxes. Those do have very specialized hardware. This
hardware e.g. allows the cpu to operate at a low frequency and therefore
those boxes may be designed cool and silent enough to be a nice thing to
enjoy.
I d
On Thu, 2003-03-13 at 00:00, Emard wrote:
> I would also suggest the global idea should be
> to try to optimize the api for budget-type cards only,
> and silently discard any onbard mpeg or hardware
> demux as if we already had mpeg2 decoder and descrambler
> in open source either in the kernel or
The V4 proposals seem reasonable.
I would also suggest the global idea should be
to try to optimize the api for budget-type cards only,
and silently discard any onbard mpeg or hardware
demux as if we already had mpeg2 decoder and descrambler
in open source either in the kernel or as external appl
Hi Rob,
Rob.McConnell wrote:
> 5. Output control. I think we need to have another look at
> this again.
> When setting up a PID filter what type of output should be
> delivered to the
> internal queue? My h/w supports the following types in
> addition to the
> dedicated A/V decoder streams
Marcus Metzler wrote:
> Johannes Stezenbach writes:
>
> > Currently the API makes no guarantee on data alignment when you read()
> > PES data from the demux. For sections, it is guaranteed that each read()
> > wil get exactly one section with the start of the section at the start
> > of the bu
HI Folks,
Just a few comments to make as well.
1. I agree that removing the dvrX device is best. The Linux s/w I
currently use to control my demux device allows you to write to it and this
would keep things consistent.
2. This arrangement is completely suitable to my current h/w config (i.e.
m
On Mon, 2003-03-10 at 15:00, Marcus Metzler wrote:
> Johannes Stezenbach writes:
>
> > Currently the API makes no guarantee on data alignment when you read()
> > PES data from the demux. For sections, it is guaranteed that each read()
> > wil get exactly one section with the start of the sectio
Johannes Stezenbach writes:
> Currently the API makes no guarantee on data alignment when you read()
> PES data from the demux. For sections, it is guaranteed that each read()
> wil get exactly one section with the start of the section at the start
> of the buffer, provided the buffer is large
Hi Johannes
>
> Question: Is there hardware support for dmx_header_filter_t? If not we
> should not add DMX_SET_EXT_FILTER to the API, let the
> application/middleware
> do it. We could add DMX_PAYLOAD_ONLY (and DMX_HEADER_ONLY?)
> to the flags
> for DMX_SET_FILTER, though (if it makes sense).
Haber, Thomas wrote:
>
> For sure section filtering is very special due to its
> header filtering. PID and stream_id filtering seems to be
> very common.
> We could put the sub stream id together
> with the stream_id in one word or we use the header filtering.
>
> so we get :
> struct dmx_fil
Haber, Thomas wrote:
>
> First i think that the difference of MPEG-1 and 2 system streams
> do not need a special reflection on the interface.
That's true, fortunately. Applications and/or the MPEG decoder
must explicitely support MPEG-1, but the demux API can
be the same for both MPEG-2 PS and M
Hi Rob,
this is true.
thomas
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Montag, 10. März 2003 12:04
> To: Haber, Thomas
> Cc: Florian Schirmer; Johannes Stezenbach; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [
ba.de> cc: "Florian Schirmer" <[EMAIL
PROTECTED]>, <[EMAIL PROTECTED]>
Sent by: Subject: [linux-dvb] Re: V4 API
proposal
Hi Johannes,
thanks for your proposal.
Johannes Stezenbach wrote:
>
> There is no "section" format for PS, so filtering the PSM and
> PSD is just the
> same as for A/V PES (the PSD even is in PES format). Also, if I'm not
> mistaken (plese correct me if I'm wrong), the MPEG-2 PS syntax is the
>
Hi Marcus und Johannes,
Marcus Metzler wrote:
>
> Johannes Stezenbach writes:
> > same as for A/V PES (the PSD even is in PES format). Also,
> if I'm not
> > mistaken (plese correct me if I'm wrong), the MPEG-2 PS
> syntax is the
> > same as the MPEG-1 System Stream syntax, so there are no a
Johannes Stezenbach writes:
> same as for A/V PES (the PSD even is in PES format). Also, if I'm not
> mistaken (plese correct me if I'm wrong), the MPEG-2 PS syntax is the
> same as the MPEG-1 System Stream syntax, so there are no additional
> requirements for the demux to process MPEG-1.
Unfo
Haber, Thomas wrote:
> Florian Schirmer wrote:
>
> > When routing/demuxing TS you do that based on:
> >
> > - PID
> > - Section filters
>
> Yes you use
> * packet id for single pes streams (audio,video, ...)
> * packet id [+ table id [+ n bytes section header Filter]] for sections
> * additi
Hi Florian,
>
> Hi,
>
> >The usage of DMX_GET_SOURCE & DMX_SET_SOURCE is suitable for
> connecting
> >demux to frontend. But how to connect Audio to a Filter ?
> >I propose to have a common mechanism for every device:
> > * To set up cascading element easily.
> > * To be able to stream to diff
Hi,
>The usage of DMX_GET_SOURCE & DMX_SET_SOURCE is suitable for connecting
>demux to frontend. But how to connect Audio to a Filter ?
>I propose to have a common mechanism for every device:
> * To set up cascading element easily.
> * To be able to stream to differnt devices in parallel.
Diffic
Ralph Metzler wrote:
> B) Generics input device
>
> Something like frontends but not bound to frontends. So you are able to
> query/set it up properly. Maybe frontends can be integrated there too? Just
> a quick idea. This will allow us to have all sorts of different inputs
> (memory or netw
Hi Florian,
>
> Hi,
>
> >I can live with both situations. A reason for having seperate device
> >is that we don't find a straight interface that is suitable for
> >both streamtypes. But if this is possible, and it makes sense, than
> >i don't see a reason why not putting them into one.
> >Tha
Hi,
Florian Schirmer writes:
> >Yes, but I wanted to know how I control the special (but common to the
> hardware type)
> >features of these devices.
>
> Sorry, i misread your mail. As i don't have any clue what properties might
> be out there else i cannot propose any suitable API for it.
Hi,
>I can live with both situations. A reason for having seperate device
>is that we don't find a straight interface that is suitable for
>both streamtypes. But if this is possible, and it makes sense, than
>i don't see a reason why not putting them into one.
>That the implementations are diff
Hi,
>Yes, but I wanted to know how I control the special (but common to the
hardware type)
>features of these devices.
Sorry, i misread your mail. As i don't have any clue what properties might
be out there else i cannot propose any suitable API for it. Here is what
somes to my mind without thin
Ho Florian,
> 2. /dev/dvb/adapterX/demuxX:
>
> A) Instead of writing TS data to the dvrX device you are now
> allowed to
> write TS data to the demuxX device.
> B) Before writing TS to it you'll have to call an ioctl to
> put the demux
> device into memory mode. (DMX_SET_SOURCE)
> C) The hardw
Florian Schirmer writes:
> >This is a little bit confusing.
> >You say if the demux has 2 frontend and 1 memory input it has
> >demux0, demux1 and demux2 but you then you say they are logical
> >devices and have to be mapped to hardware? Couldn't there be 2
> >frontends and 1 memory input b
Hi Florian,
Florian Schirmer wrote:
> Hi,
>
> >The number of demux devices should depend on
> >how many input streams can be handled in parallel.
>
> Right. But even then you can end up in a situation where 2
> users try to set
> 2 demuxes into memory reading mode, but only one memory channel
Hi,
>This is a little bit confusing.
>You say if the demux has 2 frontend and 1 memory input it has
>demux0, demux1 and demux2 but you then you say they are logical
>devices and have to be mapped to hardware? Couldn't there be 2
>frontends and 1 memory input but only 1 or 2 demux devices?
Depe
Hi,
>The number of demux devices should depend on
>how many input streams can be handled in parallel.
Right. But even then you can end up in a situation where 2 users try to set
2 demuxes into memory reading mode, but only one memory channel is
supported. In this case the driver is allowed to si
Hi Florian,
Florian Schirmer wrote:
> C) The hardware demux has to export a logical demuxX device
> for _each_ hw
> input channel it supports (e.g. if the hw supports 2 frontend
> and 1 memory
> based input it will export demux0,demux1,demux2). It is up to
> the user to
> map these logical devi
43 matches
Mail list logo
