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: [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 > > > > Hi Tom, > > Yes this is correct. > > Rob : ) > > > > > > > "Haber, Thomas" > > > <[EMAIL PROTECTED] To: > <[EMAIL PROTECTED]> > > ba.de> cc: > "Johannes Stezenbach" <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]> > 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: [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, > > > > 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" > > > > > > <[EMAIL PROTECTED] To: > > <[EMAIL PROTECTED]>, "Johannes Stezenbach" > > <[EMAIL PROTECTED]> > > ba.de> cc: > > <[EMAIL PROTECTED]>, "Ralph Metzler" > > <[EMAIL PROTECTED]> > > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Sent: Montag, 6. Oktober 2003 19:51 > > > To: Johannes Stezenbach > > > Cc: [EMAIL PROTECTED]; 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe > > linux-dvb" as subject. > > > > > > > > > > > > > > > > > > > > -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
