[mythtv-users] PVR250 + TVWonder = jerky

[michael at optusnet.com.au]

Isaac Richards <ijr at po.cwru.edu> writes:
> On Wednesday 04 June 2003 07:21 pm, michael at optusnet.com.au wrote:
[...]
> > The real solution (as I think was mentioned some time ago) is to
> > count the number of requests outstanding, and ensure that that
> > number doesn't drop below a given threshold. (i.e. no less
> > than 5 requests outstanding or some such).
> >
> > (And no, the the read ahead code doesn't fix this. It just hides the
> > problem a bit more).
> 
> Nope.  The issue is that due to the scheduler and the way all backend requests 
> are synced and due to them using the Qt event loop and everything, there's a 
> limited number of requests you can make of the backend in any given time 
> period.

I didn't find this problem in my testing. I could stream 20
megabytes/sec out of the backend with a hacked up requestor. Why do
you think this is a problem? (This is easy to test: Write a few lines
of perl to do a connect to the backend, and stuff request blocks
down as fast as you can, just counting and dumping the data the comes
back).

> Simply requesting blocks more often doesn't help -- it's still bound 
> by that limit.  Requesting _more_, however, does.

It's nothing to do with requesting more often. It's about compensating for
the latency between the front and backend.

To try and make it really really clear. Pretend that there's a 60
second network delay between the front and back. I.e. whenever you
make a request, it takes 60 seconds to get a response. ( In real life,
the backend latency varies wildly, driven by both network and disk,
and it's not constant, but it does frequently range up to 5 - 10
seconds when watching livetv)

If you RequestBlock, wait for reply, request, wait for reply, you'll never
get more than 1 block per minute. Read-ahead makes no difference.

If you do as the current code does, it will request (say) 20 blocks
before the first reply arrives. Then the frontend will never request
another block until it's used all the replies. At which point it starts
making more requests but must wait a full minute for the reply. Boom!

If you make the requests bigger, it doesn't make much difference. It
just takes a little longer for the problem to appear.

Again: The problem is that the current code frequently arrives in
the situation where it has nothing in the buffer, needs more data,
and must send a request block and then wait for the reply to
_that_ request block before proceeding.
 
> Just for fun, I tried out your previous patch and it had absolutely no effect 
> on very high bitrate ( > 14000 kbps) streams.

Using my mjpeg card on a 5 megabyte/sec stream is utterly unusable on
CVS mythtv (audio and video chops every 2 seconds). Streaming the
backend requests makes it silky smooth. (The current patch I'm
using fixes a few bugs in the original one).

PS: I know the mjpeg card has a ridiculous data rate.

Michael, now giving up.