On Sunday 09 March 2008 21:27:53 Andy Walls wrote:
> Hans Verkuil wrote:
> > On Sunday 09 March 2008 05:37:04 Andy Walls wrote:
> > > Hans Verkuil wrote:
> > > > > Here's my observation: There was no good reason for q_full
> > > > > to stay empty for so long (> 5 seconds), just because data
> > > > > was sitting queued in q_io. It was as if data stopped being
> > > > > moved from the encoder to buffers and into q_full. What is
> > > > > both fortunate and unfortunate is that draining q_full and
> > > > > q_io,
> >
> > seems
> >
> > > > > to restart the transfers from the encoder.
> > > > >
> > > > >
> > > > > So to test these hypotheses, I'll have to gain some
> >
> > understanding
> >
> > > > > of the new mailbox protocol and the Memory Descriptor List
> > > > > stuff and do some testing with the fix to
> > > > > cx18_v4l2_enc_poll() backed out.
> > > >
> > > > Look for 'CX18_CPU_DE_SET_MDL' in cx18-fileops.c: this is where
> >
> > the
> >
> > > > processed buffer is returned to the firmware so that it can be
> >
> > used
> >
> > > > again. Based on your description I was wondering whether in
> > > > some cases all or most buffers are in use and the firmware will
> > > > just stop capturing due to a lack of available buffers.
> > >
> > > Argh. I'm giving up on hunting this down for now. Here are my
> > > observations and speculations with the return value of
> > > cx18_v4l2_enc_poll() does not depend on q_io.length:
> > >
> > > a) The most buffers I've ever seen in use in the driver are 1 in
> >
> > q_io
> >
> > > and 10 in q_full. That was when then encoder decided to give the
> > > driver 10 buffers all at once. (What good is q_io anyway in the
> >
> > cx18
> >
> > > driver? It seems like a lot of book keeping just to store the 1
> > > partially read buffer. Would pushing a partially read buffer
> > > back
> >
> > on
> >
> > > the head of q_full be that hard?)
> >
> > This code is basically copied from ivtv (where bookkeeping is much
> > more
> > complicated still). It might well be replaced by just pushing it
> > back to q_full for this driver.
>
> I thought so. I was also toying with the idea of more granular
> locking for the queues: one lock for each q_free, q_full, and q_io.
> In which case, if I could work out not deadlocking on q_free, I'd
> want q_io and q_full to remain separate.
>
> Anyway, q_io's fate isn't critical at the moment.
>
> > > b) I can always get the transfer from the encoder to stall.
> > >
> > > c) stopping the capture, reloading all the MDLs and restarting
> > > the capture doesn't make transfers from the encoder work again.
> > >
> > > d) a common sequence of failure looked like the following, with
> > > the encoder sending a small (2048 bytes) buffer, the driver
> > > returning 2 MDLs very close together, and then the encoder
> > > sending only one more buffer:
> >
> > ...
> >
> > > I changed the cx18_read() function to exit the loop and return
> > > once it had returned 1 MDL to the encoder, but the problem still
> > > persisted. In this case the short buffer in at least one trial
> > > was 4096 bytes.
> > >
> > >
> > > e) I don't know what to make of it all without some specific
> >
> > commands
> >
> > > to query the encoder's status, use of MDLs, and timeouts. I
> > > could take a closer look at the MDL acks and the irqs and irq
> > > acks, but
> >
> > I'm
> >
> > > not that motivated at this point. The driver/encoder transfer
> > > performance is good enough for me for now with the return value
> >
> > logic
> >
> > > of the cx18_v4l2_enc_poll() function fixed.
> >
> > Is it possible to reproduce it by writing a small capture program
> > that
> > acts similar to MythTV? If I had a program like this, then I could
> > investigate.
>
> Just to be clear for list readers: for one stream (MPEG) being
> provided by the firmware, the current cx18 driver works well for any
> application that uses a minor amount of buffering. I also works well
> with a strong , clean video signal for applications that don't
> buffer. MythTV uses a lot of buffering. Mplayer doesn't do
> buffering (unless specifically asked with the -cache option), but on
> most stations, it performs well, with a minor glitch occasionally for
> stations with weak signals.
>
>
> Yes, if I have time, I can write a program to emulate the critical
> aspects of MythTV's operation. You will have to back out the fix to
> cx18_v4l2_enc_poll() to purposely induce the stall. Also tuning to a
> weak, snowy channel (but not all snow) and changing channels will
> induce the problem more rapidly. I assume the encoder can't compress
> as well under these circumstances, so it sends more data to the host.
>
> I will be on travel for the better part of the next two weeks. If I
> don't post a test program on Monday, 10 March, don't expect anything
> until Friday, 21 March at the earliest. (I'll be home for a few days
> in the middle of that stretch, but that time is booked with home
> maintenance and family time).
>
> Regards,
> Andy
Well, the same is true for me, I doubt I'll get anything done until
after Easter.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
