Hans Verkuil wrote: > On Sunday 23 March 2008 03:27:56 Andy Walls wrote: > > On Fri, 2008-03-21 at 22:04 -0400, Andy Walls wrote: > > > On Sun, 2008-03-09 at 16:28 -0400, 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. > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > 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. > > > > > > > > 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. > > > > > > Hans, > > > > > > Attached is the test program for which you asked. With it, you > > > should be able to reproduce select() timeouts with > > > cx18_v4l2_enc_poll() modified to not watch q_io. So you can at > > > least get the encoder transfers to stall for 5 seconds. > > > > > > I have not been able to get the test program to stall the encoder > > > transfers long term yet. I'll have to make it more MythTV-like, I > > > guess, by calling some of the ioctls that MythTV does. > > > > Hans, > > > > Attached is an updated version of the test program that sets up the > > device with ioctl()s as MythTV would. The item that made the > > difference on reproducing the "permanent" stall was the setup_vbi() > > function. > > Thanks Andy, > > I can reproduce it but it is not entirely clear what is going on. It > looks like a buffer that isn't thrown back into the MDL pool fast > enough. Or something like that. To be continued.
Again, if you eliminate the call to setup_vbi() in the test program, things are "fine". > BTW: check out my latest cx18 tree, apparently ATSC is now working > thanks to the hard work of Steve Toth. I saw Steve making check-ins last night and you making some changes today, so I was waiting for the "churn" to die down. Later this evening I may get a chance to test things. Linux's DVB device nodes and API are new to me, so I'll have to climb the learning curve. (Hopefully mplayer or MythTV has it figured out for me already.) I'll only be able to test ATSC 8VSB, as that's the only modulation I have ever received over the air. I don't have cable, so ATSC QAM modulations (and the little used 16VSB modulation) have to be tested by someone else. > Regards, > > Hans > > > > > Note that upon further investigation the encoder isn't completely > > non-responsive. After closing and reopening the stream, it will > > produce one transfer into q_full. If nothing drains off q_full/q_io > > after that, it will not produce another transfer until the stream is > > closed and reopened again. For the MythTV user experience, this > > amount to a black screen and repeated select timeouts. > > > > Again, the fix to cx18_v4l2_enc_poll() to watch q_io now masks this > > bug. > > > > Regards, > > Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
