Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: Linux DVB API 4 Q's
Hi Rob,
So this is only a change in the semantics.
The API needs not need to be changed.
The autostart can be given with the set ioctl.
The add/remove ioctl only have the pid as parameter.
Start iioctl needs to be called after each group of add commands
when autostart has not been set.
I am open to this, even if i don't see the usecase on our side.
If you get some packets of the video before you get audio does not harm.
In any case when you start a sequence you will start the audio smoothly.
And before you get the first picture from the screen it take about half a second.
So we don't worry.
regards,
tom
> -----Original Message-----
> From: Rob.McConnell@Zarlink.Com [mailto:Rob.McConnell@Zarlink.Com]
> Sent: Dienstag, 7. Oktober 2003 12:17
> To: Haber, Thomas
> Cc: Johannes Stezenbach; linux-dvb@linuxtv.org
> Subject: RE: [linux-dvb] Re: Linux DVB API 4 Q's
>
>
>
> Hi Tom,
>
> Yes this is correct.
>
> Rob : )
>
>
>
>
>
>
> "Haber, Thomas"
>
>
> <THaber@tee.toshi To:
> <Rob.McConnell@zarlink.com>
>
> ba.de> cc:
> "Johannes Stezenbach" <js@convergence.de>,
> <linux-dvb@linuxtv.org>
> Subject: RE:
> [linux-dvb] Re: Linux DVB API 4 Q's
>
> 07-Oct-2003 11:14
>
>
> AM
>
>
>
>
>
>
>
>
>
>
>
>
> Basic difference in your proposal is that
> when you add a filter without autostart, the filter is not started,
> even if there was an START ioctl before on the fd.
> Another START ioctl will start the added filters and will not
> touch the
> allready started ones.
>
> Is this correct?
>
>
>
> tom
>
> > -----Original Message-----
> > From: Rob.McConnell@Zarlink.Com [mailto:Rob.McConnell@Zarlink.Com]
> > Sent: Dienstag, 7. Oktober 2003 12:04
> > To: Haber, Thomas
> > Cc: Johannes Stezenbach; linux-dvb@linuxtv.org; Ralph Metzler
> > Subject: Re: [linux-dvb] Re: Linux DVB API 4 Q's
> >
> >
> >
> > Hi Again,
> >
> > Why don't we do the obvious which is to allow the
> > DVB_DMX_START ioctl start
> > all filters on the fd. This means that we can add new
> > filters or remove
> > old ones (after stopping) and then issue the START ioctl to
> > start the new
> > ones. Any old filters that were already running won't be affected.
> >
> > e.g. Already recording BBC1 on hdd and user wants to record
> > BBC2. Simply
> > use the DVB_DMX_ADD_PID_FILTER to individually add the
> > necessary AUDIO,
> > VIDEO and possibly SUBTITLE PID filters for BBC2. Then issue the
> > DVB_DMX_START ioctl on the "global" fd and all is well. The
> > newly added
> > filters will start immediately (well as fast as Linux can) and you
> > shouldn't have any problems with one filter lagging behind another.
> >
> > If the user wants to stop recording BBC2 and start recording
> > BBC3 instead,
> > then the DVB_DMX_DEL_PID_FILTER could be used to remove the
> individual
> > filters associated with BBC2 (it would stop filtering first).
> > Then the
> > DVB_DMX_ADD_PID_FILTER would be used in conjunction with
> > DVB_DMX_START to
> > setup the necessary filters individually and hit the go button.
> >
> > Getting back to the delayed audio, there isn't an issue with
> > lip-sync but
> > rather the delay itself could be 10ms or more on slow
> > processors. If you
> > issue a system call to setup a video PID filter with the
> > DVB_DMX_IMMEDIATE_START flag set and then the next line in
> > your user app
> > says to setup an audio PID filter (again with the
> > DVB_DMX_IMMEDIATE_START
> > flag set), there could be a long time between these 2
> > statements. This is
> > simply because the scheduler under Linux will look to see what other
> > processes to run at the end of a system call (and other
> > places). If one of
> > the processes it chooses to run is long, then you may not
> get back in
> > reasonable time to execute the set audio pid filter syscall.
> > Under fast
> > machines, then this is probably not a problem, but STB
> > processors (100MHz
> > +) could pose a problem.
> >
> > All in all, it is better to cater for any eventuality, so
> > this is why it is
> > better to have both DVB_DMX_IMMEDIATE_START flag and
> > DVB_DMX_START ioctls.
> >
> > So:
> > 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 individually ADD & START a filter issue the
> > DVB_DMX_ADD_PID_FILTER
> > ioctl with the DVB_DMX_IMMEDIATE_START flag set.
> >
> > 3) To START a group of filters at once, issue the
> > DVB_DMX_START ioctl on
> > the required fd.
> >
> > 4) To STOP a group of filters (e.g. pausing), issue the
> > DVB_DMX_STOP ioctl
> > on the required fd.
> >
> > 5) To individually STOP and remove a filter issue the
> > DVB_DMX_DEL_PID_FILTER ioctl.
> >
> >
> > OK, does this look reasonable?
> >
> > Rob : )
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > "Haber, Thomas"
> >
> >
> > <THaber@tee.toshi To:
> > <Rob.McConnell@Zarlink.Com>, "Johannes Stezenbach"
> > <js@convergence.de>
> > ba.de> cc:
> > <linux-dvb@linuxtv.org>, "Ralph Metzler"
> > <rjkm@metzlerbros.de>
> > Sent by: Subject:
> > [linux-dvb] Re: Linux DVB API 4 Q's
> >
> > linux-dvb-bounce@
> >
> >
> > linuxtv.org
> >
> >
> >
> >
> >
> >
> >
> >
> > 07-Oct-2003 08:15
> >
> >
> > AM
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Rob,
> >
> > your arguments are not obvious to me.
> > Maybe its because i did not follow the whole thread.
> >
> > If i understood it right you can add filter and do afterwards
> > the start.
> > And even if you use autostart, and your audio start will be delayed,
> > this does not mean that your audio is not in lip sync,
> > it only starts some time later (10 ms is nothing in here).
> >
> > regards,
> >
> > tom
> >
> >
> > > -----Original Message-----
> > > From: Rob.McConnell@Zarlink.Com [mailto:Rob.McConnell@Zarlink.Com]
> > > Sent: Montag, 6. Oktober 2003 19:51
> > > To: Johannes Stezenbach
> > > Cc: linux-dvb@linuxtv.org; Ralph Metzler
> > > Subject: [linux-dvb] Re: Linux DVB API 4 Q's
> > >
> > >
> > >
> > >
> > >
> > > > > 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 proposal.
> > >
> > > > But I am not convinced that your requirement is
> reasonable. If you
> > > > do a few ADD_PID or DEL_PID calls in succession, they would
> > > > typically be only microseconds apart (possibly a few
> milliseconds
> > > > if the system load is high). Why is that a problem?
> > >
> > > From a Q.A. point of view, the audio and video should not be
> > > out by greater
> > > than 10ms (in terms of audio lagging behind the video). Can
> > we really
> > > guarantee this requirement between successive system calls?
> > > What happens
> > > if you execute the first system call to setup the video PID
> > > and when it
> > > exits the scheduler decides to execute some other process
> > > that could be
> > > very time consuming? We may not get back to setting up
> the audio or
> > > subtitle PID for quite some time later. Don't forget that
> > we are not
> > > running on 1GHz+ uProcessors, but rather more like 100MHz+.
> > If we can
> > > setup the video/audio/subtitle PIDs all in one go, then
> at least we
> > > wouldn't have this worry.
> > >
> > > Rob :^)
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Info:
> > > To unsubscribe send a mail to ecartis@linuxtv.org with
> > > "unsubscribe linux-dvb" as subject.
> > >
> > >
> >
> >
> >
> **********************************************************************
> > CONFIDENTIALITY DISCLAIMER
> >
> > The information in this email and in any attachments is
> > confidential and
> > may be
> > privileged. If you are not the intended recipient, please
> > destroy this
> > message,
> > delete any copies held on your systems and notify the sender
> > immediately.
> >
> > You should not retain, copy or use this email for any purpose
> > outside of
> > any NDA
> > currently existing between Toshiba Electronics Europe GmbH
> > and yourselves.
> >
> **********************************************************************
> >
> >
> >
> > --
> > Info:
> > To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe
> > linux-dvb" as subject.
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.
Home |
Main Index |
Thread Index