On Monday 12 June 2006 08:49, Martin Dauskardt wrote:
> > On Wednesday 07 June 2006 09:03, Martin Dauskardt wrote:
> > > > From: Hans Verkuil <[EMAIL PROTECTED]>
> > > >
> > > > > But why is there such a long delay with the recommended
> > > > > ioctl? What makes the difference? How can I improve it?
> > > >
> > > > No idea. Try to set from debug messages in
> > > > ivtv_stop_v4l2_decode_stream() to see what part takes so much
> > > > time.
> > >
> > > Hi Hans,
> > > could you describe this a little more? Which debug level do you
> > > recommend for this?
> >
> > No, I mean just add printk() messages at several places in the
> > function. You can see the timestamps of when the message was logged
> > in (usually) /var/log/messages. So if you see a sizeable gap in
> > timestamps between two printk's, then the code in between must be
> > the culprit. It's old-fashioned, but it works.
>
> I am still not sure in which area I should set the printk`s. With
> debug level 21 set I now have the impression that it is not the stop
> decode area, but the start decode area. That`s strange, because
> starting the decoder works with the same ioctl commands very fast, if
> the decoder is _stopped_ before with a fwapi call.
Just put printk() calls (e.g. printk("1\n");) at several places inside
the ivtv_stop_v4l2_decode_stream() function. For example at the
beginning, before and after the first and second for-loops and at the
end. In the log you will see how much time it costs to go from one
printk to the next. It's just a cheap way to time things. The text in
the printk has no other meaning then to identify which printk it is.
As John also mentioned, the startup delay is caused by the driver
filling the internal buffers with enough data to begin feeding the
decoder. Unrelated to the stop problem.
Another thought: why DO you need to stop/start the decoder while
switching channels? There is no need to do that as far as I can see.
This way you are always stuck with having to fill up the internal
buffers again when you start the decoder.
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
