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 _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
