Hi Again,
> I'm just reading
> http://linuxtv.org/mailinglists/linux-dvb/2003/03-2003/msg00116.html
> I'm currently inclined to drop enum dvb_dmx_source_type and just
> use the frontend file descriptor in DVB_DMX_SET_SOURCE.
> For stream playback or external inputs we could add other
> input
Hi,
> On Mon, Sep 22, 2003 at 09:27:07PM +0200, Ralph Metzler wrote:
> > [EMAIL PROTECTED] writes:
> > >
> > > A. If we want to route a TS/PS/PES off a DVD or HDD through a PID
filter,
> > > then I guess we would have to setup the source type of the filter to
be
> > > "DVB_DMX_SOURCE_FRONT
Hi,
On Mon, Sep 22, 2003 at 09:27:07PM +0200, Ralph Metzler wrote:
> [EMAIL PROTECTED] writes:
> >
> > A. If we want to route a TS/PS/PES off a DVD or HDD through a PID filter,
> > then I guess we would have to setup the source type of the filter to be
> > "DVB_DMX_SOURCE_FRONTEND" with the c
> [EMAIL PROTECTED] wrote:
> >
> > 1. Open up an fd on the demux device and use the DVB_DMX_ADD_PID_FILTER
> > ioctl passing in the PIDs of the video,audio and subtitle streams of
BBC1.
> > Immediately the PID filters will be activated and start filtering data
to
> > the h/w buffers. In this i
Haber, Thomas wrote:
> I still prefer the current V4 proposal, with
> set(struct)/add(pid)/remove(pid)/start/stop and autostart. So far i
> don't see a usecase that is not shot.
How would you generate I-frame events if you cannot pass
the filter_type along with the pid?
We'd need to change the D
[EMAIL PROTECTED] wrote:
>
> 1. Open up an fd on the demux device and use the DVB_DMX_ADD_PID_FILTER
> ioctl passing in the PIDs of the video,audio and subtitle streams of BBC1.
> Immediately the PID filters will be activated and start filtering data to
> the h/w buffers. In this instance, the DV
04
> To: Haber, Thomas
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Ralph Metzler
> Subject: Re: [linux-dvb] Re: Linux DVB API 4 Q's
>
>
> Haber, Thomas wrote:
> > Where do you want to transfer the parameters beside the pids.
> > You still want to keep the set ?
>
Haber, Thomas wrote:
> Where do you want to transfer the parameters beside the pids.
> You still want to keep the set ?
Well, how do we handle e.g. DVB_DMX_WAIT_FOR_PUSI? Do we need to
set it different for each PID? If so, ADD will have to pass an array of:
struct {
enum dvb_dmx_filter_ty
> I would prefer to:
> - pass an array of PIDs to ADD/DEL
> - remove the DVB_DMX_IMMEDIATE_START, DVB_DMX_START and DVB_DMX_STOP
ioctls
> While I don't think that it's important for me to set a number of
> filters at exactly the same time, this would simplify error handling
> because we can m
OTECTED]; Ralph Metzler
> Subject: Re: [linux-dvb] Re: Linux DVB API 4 Q's
>
>
> [EMAIL PROTECTED] wrote:
> >
> > 1) DVB_DMX_START and DVB_DMX_STOP ioctls will globally
> work on any filters
> > attached to a single fd. I guess the advantage of keeping
> t
[EMAIL PROTECTED] wrote:
>
> 1) DVB_DMX_START and DVB_DMX_STOP ioctls will globally work on any filters
> attached to a single fd. I guess the advantage of keeping the DVB_DMX_STOP
> ioctl is to reduce any time required to do an "open" on a new fd after you
> did a "close".
>
> 2) To individual
b : )
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 7. Oktober 2003 12:17
> To: Haber, Thomas
> Cc: Johannes Stezenbach; [EMAIL PROTECTED]
> Subject: RE: [linux-dvb] Re: Linux DVB API 4 Q's
>
>
>
>
don't worry.
regards,
tom
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 7. Oktober 2003 12:17
> To: Haber, Thomas
> Cc: Johannes Stezenbach; [EMAIL PROTECTED]
> Subject: RE: [linux-dvb] Re: Linux DVB API 4 Q's
>
>
AIL
PROTECTED]>, <[EMAIL PROTECTED]>
Subject: RE: [linux-dvb] Re: Linux DVB
API 4 Q's
07-Oct-2003 11:14
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 7. Oktober 2003 12:04
> To: Haber, Thomas
> Cc: Johannes Stezenbach; [EMAIL PROTECTED]; Ralph Metzler
> Subject: Re: [linux-dvb] Re: Linux DVB API 4 Q's
>
>
>
> Hi Again,
>
a.de> cc: <[EMAIL PROTECTED]>, "Ralph
Metzler" <[EMAIL PROTECTED]>
Sent by: Subject: [linux-dvb] Re: Linux DVB API
4 Q's
linux-dvb-bounce@
,
it only starts some time later (10 ms is nothing in here).
regards,
tom
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Montag, 6. Oktober 2003 19:51
> To: Johannes Stezenbach
> Cc: [EMAIL PROTECTED]; Ralph Metzler
> Subject: [linux-
> > Ahh, maybe if we implement your DVB_DMX_SET_PID_FILTER with an array of
> > PIDs to set and start immediately using the DVB_DMX_IMMEDIATE_START
flag,
> > we can nicely obtain this requirement.
> >
> > Do these ideas sound reasonable?
> If I were to implement it I would go with your last pro
[EMAIL PROTECTED] wrote:
>
> I need to be able to setup many filters on an fd and then hit the "go
> button" to make them active. Like I said before, it would be nice then to
> stop or close filters that you don't need on the fly and add some new ones
> altogether and start them all at once
> > > So both DVB_DMX_START and DVB_DMX_STOP ioctls in this case would
have to
> > > have a handle to the filter required. In this case, why not specify
the
> > > pid value as in the proposition for the ADD/DEL ioctl above?
> >
> > For the ADD/DEL ioctl I agree. For the application you are
Hi,
[EMAIL PROTECTED] wrote:
> >
> > If we use the ADD/DEL ioctl to be able to "attach" PID filters to an
> > existing fd so that we have a multiplexed output stream, then we will
need
> > to identify which PID filter to remove using the DEL ioctl. Currently
in
> > the dmx.h header file the D
Ralph Metzler wrote:
> [EMAIL PROTECTED] writes:
> > How should we treat the DVB_DMX_START and DVB_DMX_STOP ioctls for an fd
> > that has many PID filters associated with it? Should these ioctls START
> > and STOP all filters attached to the fd simultaneously, or would it be
> > better to sing
Hi,
[EMAIL PROTECTED] wrote:
>
> If we use the ADD/DEL ioctl to be able to "attach" PID filters to an
> existing fd so that we have a multiplexed output stream, then we will need
> to identify which PID filter to remove using the DEL ioctl. Currently in
> the dmx.h header file the DVB_DMX_DEL_PI
>[EMAIL PROTECTED] writes:
> > How should we treat the DVB_DMX_START and DVB_DMX_STOP ioctls for an fd
> > that has many PID filters associated with it? Should these ioctls
START
> > and STOP all filters attached to the fd simultaneously, or would it be
> > better to single out specific filter
[EMAIL PROTECTED] writes:
> How should we treat the DVB_DMX_START and DVB_DMX_STOP ioctls for an fd
> that has many PID filters associated with it? Should these ioctls START
> and STOP all filters attached to the fd simultaneously, or would it be
> better to single out specific filters to STAR
Hi,
> If we use the ADD/DEL ioctl to be able to "attach" PID filters to an
> existing fd so that we have a multiplexed output stream, then we will
need
> to identify which PID filter to remove using the DEL ioctl. Currently in
> the dmx.h header file the DVB_DMX_DEL_PID_FILTER accepts the fd
Hi Again,
> > Could you run through the advantages of the SET ioctl over the add/del.
> > Personally I would still rather stick with ADD/DEL as user applications
> > would typically use these methods to set up PES filters when changing a
> > programme or as and when required. I guess the SET
> > Or how do you handle the case if two demuxes are supposed to process
> > the same data from memory?
> Good point. Not that I think that this case will be used much in
> practise, but we shouldn't prevent it from in the API design.
If you had N logical demux devices to cater for the h/w tha
Hi,
[EMAIL PROTECTED] wrote:
>
> Sorry, my mistake. I understand that you will have a /dev/dvb/adapter0/ci0
> and /dev/dvb/adapter0/ci1 device node for 2 slots (or N slots) independent
> of whether the same TS is delivered to each or whether you have a separate
> TS routed to each CAM.
I planne
>[EMAIL PROTECTED] wrote:
> >
> > One CI device per slot would be fine for our requirements. I guess if
you
> > had 2 slots and only one physical CI device you could always create
another
> > logical CI device to handle the extra slot. Was this your thinking as
> > well?
> You're confusing m
[EMAIL PROTECTED] wrote:
>
> One CI device per slot would be fine for our requirements. I guess if you
> had 2 slots and only one physical CI device you could always create another
> logical CI device to handle the extra slot. Was this your thinking as
> well?
You're confusing me. What extra sl
Hi Again,
> > > That would be one possible way.
> > > Btw., I have a question regarding the new CI devices and how to
differentiate
> > > several CI adapters (not that I know receivers with more than one).
> > > If you have one CI device for each slot, you might want to call
> > > them ci0_0, c
[EMAIL PROTECTED] wrote:
>
> > > What about leaving the demux device alone and allowing it to choose say
> > > front_end x = C/A module input. Then we
> > > need a C/A device that can set it's source to say external demod #1. In
> > > this case, h/w that does have the ability to route an input TS
Hi Again,
[EMAIL PROTECTED] writes:
> > > Both, one section filter for several PIDs and several filters on one
> > > PID, would be useful to have on one file descriptor in some special
> > > cases. But both make the demuxer more complicated and only move
> > > complexity from user space into the
Hi Ralph,
> Yes, you can add several section filters to a section feed. But these
> are internal data structures which take into consideration that
> most hardware has no completely separate section filters but that they
> all have to be associated with a PID filter (or some call them PID feed
[EMAIL PROTECTED] wrote:
> > You can have more than one section filter per PID, but not on
> > the same fd. You have to open a new demux fd for each filter.
>
> That's perfect for what we want to do. Does the V3 API currently support
> this?
Yes.
Johannes
--
Info:
To unsubscribe send a mail
Hi,
> You can have more than one section filter per PID, but not on
> the same fd. You have to open a new demux fd for each filter.
That's perfect for what we want to do. Does the V3 API currently support
this?
> > Yes I agree, but if we have the generic OTHER type then that has to
cover
>
Hi Johannes,
> Hi,
> lots of questions, so it takes some time for me to go through them,
> but they are highly appreciated!
Yup, its been a busy day on the keyb, but I think we all have benefitted :
)
> See my other posting. Current software uses on fd per PID, so it doesn't
> matter. IMHO i
[EMAIL PROTECTED] wrote:
>
> > The current API only allows one filter per fd, so when converting
> > old sw to the new API it doesn't matter.
>
> We should definitely allow multiple section filters to be attached to a
> single PID. I need it for my design and I will end up implementing anyway
>
> SET vs. ADD/DEL is simpler in that it implicitly prevents
> inconsistent flag settings, e.g. one filter with
> DVB_DMX_OUT_MEMORY and the ADD one without DVB_DMX_OUT_MEMORY.
> The current API only allows one filter per fd, so when converting
> old sw to the new API it doesn't matter.
We sh
Hi,
lots of questions, so it takes some time for me to go through them,
but they are highly appreciated!
[EMAIL PROTECTED] wrote:
> > No, we don't care about AVPES anymore. That's left for userspace.
> > PES means a stream of video + audio (and maybe other) PES packets
> > without (PS) pack struc
[EMAIL PROTECTED] writes:
> I beg to differ on this. If you have a look at dvb_demux.c there is the
> function "dvb_dmx_swfilter_section_feed" that gets called when we have some
> section data available from the h/w. In this function we have a pointer to
> a "dvb_demux_filter" that is set fro
[EMAIL PROTECTED] writes:
> > Both, one section filter for several PIDs and several filters on one
> > PID, would be useful to have on one file descriptor in some special
> > cases. But both make the demuxer more complicated and only move
> > complexity from user space into the kernel. It is no
> [EMAIL PROTECTED] wrote:
> >
> > As I understand the current API version 3 implementation allows you to
> > attach multiple section filters to a single fd, so I think we should
keep
> > this in V4.
> Nope. Only one filter per fd.
I beg to differ on this. If you have a look at dvb_demux.c t
Hi,
[EMAIL PROTECTED] wrote:
>
> As I understand the current API version 3 implementation allows you to
> attach multiple section filters to a single fd, so I think we should keep
> this in V4.
Nope. Only one filter per fd.
> What about leaving the demux device alone and allowing it to choose s
Ralph Metzler wrote:
> [EMAIL PROTECTED] writes:
> > Could you run through the advantages of the SET ioctl over the add/del.
> > Personally I would still rather stick with ADD/DEL as user applications
> > would typically use these methods to set up PES filters when changing a
> > programme or a
Hi Guys,
Thanks for the prelim comments : )
> > As long as we have the capability to add multiple PID filters to an fd
for
> > a TS or PES output, then that should be OK (e.g. for recording to HDD).
> > For section filtering, I suppose it would make sense to have different
fds
> > for the sa
[EMAIL PROTECTED] writes:
> Could you run through the advantages of the SET ioctl over the add/del.
> Personally I would still rather stick with ADD/DEL as user applications
> would typically use these methods to set up PES filters when changing a
> programme or as and when required. I guess t
Hi Again,
A few more Q's regarding the V4 API...
> > Have a few Q's about the header files in the V4 API dir in CVS:
> >
> > 1: I see that the "dvb_dmx_source_format" has a new format called PES.
Is
> > this to cover proprietary formats such as AVPES?
> No, we don't care about AVPES anymore.
Hi,
[EMAIL PROTECTED] wrote:
>
> Seen that there is work being done on the V4 API now. Does this mean that
> it is full speed ahead on V4 now, or are there other loose ends to fixup
> first?
There was some (little) discussion in private mail, and then
I read through the postings on this subject
50 matches
Mail list logo
