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 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