Cool, sounds good mostly. The wait for the decoding to stop is assuming the application knows how much video it want's to decode and stops feeding the decoder right at the point they want it to stop display. So it's just finishing off what it is given, so giving it very small chunks will work, and seems like very likely part of the reason ff/rw works good now.
I think we need a parameter to stop decoding, probably the ioctl, which would choose to just discard the buffers, not the current flush decoder one, that's for after stoping decoding and is only really needed in the driver to re-queue the used buffers, but just tell the stop command to not decode the remaining buffers. Something to experiment with, basically we have alot more control of stopping the decoder now and so there's two new settings we need to incorporate and give applications a greater and smoother control of playback. The 'no-stop' flag, which seems to be a way to keep the decoder on, but stop decoding, so the next start to decode is a very smooth spliced entry. The 'fast-stop' flag, which would say to stop the decoder without decoding anymore buffers, else we would usually treat all the input data until it stops as desired output. These are there for those wanting and able/knowing about the userend of things and how to make some patches for Myth and the driver to have ioctls and the right actions to improve ff/rw and general decoding. Also I still need to modify the function to stop decoding to have an input variable to do the fast-stop option, although then we'd still need an ioctl to set that (or possibly make it the default to fast-stop, next thing I'm working on currently ;-). Thanks, Chris On Wed, Apr 27, 2005 at 09:57:23PM +0200, Nick Rosier wrote: > Chris, > > so far I've not noticed any hangs with this driver or 0.3.3q (mainly > been playing with the latter one) so that seems a good thing. Been > really torturing it; skipping forwards, backwards, FF/RW at different > speeds, slowing down, speeding up. Just great so far. > > But I've noticed a couple of side-effects in MythTV: when pausing, > skipping forward, backward etc.. the recording seems to continue for > about 1 to 2s before making the requested operation (which can throw > you off track, did the remote work?). It's as if it's waiting for it's > buffers to drain. > Simular, when you exit watching a recording, it takes a couple of > seconds and the OSD doesn't display it's saving the current position. > > Major step forward; the (random) hangs were much more annoying than this is > :-) > > N. > > On 4/27/05, Chris Kennedy <[EMAIL PROTECTED]> wrote: > > I added a variable to be used in stop decoding with the dec_options, which > > will change the stop conditions of the decoder to not shut it down > > completely, which seems to allow splicing to work really well. This isn't > > set in the ioctl, still not sure (I manually set static it for my setup in > > splicer in the driver right now), but probably could be added as an ioctl > > in the future when splicing. > > > > #0.3.3r: http://www.ivtv.tv/releases/ivtv-0.3/ > > > > Thanks, > > Chris > > > ------------------------------------------------------- > SF.Net email is sponsored by: Tell us your software development plans! > Take this survey and enter to win a one-year sub to SourceForge.net > Plus IDC's 2005 look-ahead and a copy of this survey > Click here to start! http://www.idcswdc.com/cgi-bin/survey?id5hix > _______________________________________________ > ivtv-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id5hix _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
