On Friday 07 March 2008 01:09:27 Andy Walls wrote:
> Hans Verkuil wrote:
> > On Thursday 06 March 2008 05:29:19 Andy Walls wrote:
> > > Attached is a patch to have cx18_v4l2_enc_poll() to return that
> > > data is available for reading when q_io has data. The case could
> > > occur that q_full was empty, but q_io had data waiting to be
> > > read, in which case cx18_v4l2_enc_poll() probably should have
> > > returned data is ready for reading.
> >
> > Nice catch! I've committed this. Interestingly enough, I think the
> > same bug is also present in ivtv. I'll look at that tonight.
>
> Thanks.
>
> Yes, I noted the bug in ivtv as well, but I left it alone since I was
> tired and ivtv uses q_io differently for write streams to the
> cx23415's decoder.
>
>
> However this patch isn't the end of fixing poll()/select() for cx18.
> Though this simple patch is correct and necessary, I suspect it will
> now mask another underlying problem.
>
> 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.
>
> mplayer never had a problem with cx18 never providing new data
> eventually, because it was always draining q_io and q_full. MythTV
> would never drain q_io and the data transfers from the encoder would
> never restart.
>
> This behavior of having to drain q_full and q_io to restart the data
> transfers may be why I notice blocking read() delays of about 0.1
> second happening much more often than with ivtv.
>
> 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.
> But hey for now, the majority of HVR-1600 MythTV users should be much
> happier. :)
>
> > I'll also look at the other patch tonight: I think you found a
> > serious bug with that one as well.
>
> Thanks again. I was going for the bugs I could fix without data
> sheets. That fix was a hard fought change to only 5 lines of code.
>
> > Thank you!
>
> You're welcome. I enjoyed working on these problems. I guess my
> irrational desire for Picture-in-Picture can be a good thing at
> times. ;)
Dangerous. I started out working on ivtv due to an irrational desire to
capture a widescreen signal and I ended up as ivtv maintainer :-)
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
