[mythtv] HD3000 buffer overrun solution - patches for hdtvrecorder.cpp/.h against mythtv 0.16

John Patrick Poet john at BlueSkyTours.com
Mon Dec 6 23:57:33 UTC 2004



On Mon, 6 Dec 2004, Eric Anderson wrote:

>
> Hi John -
>
> If you can, please send me your patch. I'm interested to see how you
> did it.
>
> Wow, 96MB of buffering. That's quite a bit. Especially with 3 going.


If I didn't have 1 gig in that machine, I would be in trouble.


> Clearly the more processing that gets in-lined with decoding the HDTV
> stream makes it harder for an underpowered system to keep up. So while
> it's nice to have the closed-caption information decoded, at some point
> there's going to be a limit to how much can be decoded before you just
> can't keep up. (Although -- *most* of the ATSC packets are still going
> to be video information. So perhaps the amount of overhead processing
> for things such as closed-caption and program information won't be so
> bad?)
>
> Now, it sounds like with 3 streams and the new code, you're really not
> keeping up while running Daniel's code. So your buffer is almost always
> gradually filling, right? And when you finally overflow, it's pretty
> much game
> over, if I understand correctly.


Yup.  I have never done any "real time" programs before, so my original
attempts were very efficent, and did not work worth a damn.  Once I got my
mind arround that fact that response time was critical, not efficiency, I
managed to get it working -- to a point.


> For my system, my original goal was to get just 1 stream working
> without buffer
> overruns. And without the read() thread, I was getting buffer overruns
> whenever
> I did any serious amount of disk or CPU activity.


Yeah.  This happened to me even with the HD-2000, but the HD-3000 is worse.


> I guess one thing that could be added would be a piece of code that
> computes
> a moving average of the buffer depth over time. If the buffer is
> steadily increasing
> over time, mythbackend could take some action. Examples:
>
>           1. Simplest would be to print a warning as in:
>              "Mythbackend is falling behind. Estimating %d seconds to
> buffer exhaustion..."
>
>           2. Next easiest would be to try to turn off some of the backend
>              decoding functionality (although I'm not sure how much you
> buy
>              by doing that).
>
>           3. Most complicated would be to spawn yet another thread and
>              shuffle data to a temporary file. Unfortunately, by doing
> that you've
>              now just increased the amount of I/O that you have to do by
> 2x -- so
>              it may be a losing proposition. Essentially, you get closer
> to doing a
>              two-pass operation. But by the time you get this far, maybe
> it's time to
>              buy a second PC to hold the 3rd card? =)


With three streams going, it becomes a balancing act.  It is actually not a
problem reading the data from the HD-3000 quick enough.  The real problem is
writing the data to disk quick enough.

It is better to read and process small amounts of data quickly and
frequently, rather than large amounts of data efficiently.

"IOBOUND"s in the diskwriter thread are what cause my overruns at this
point.  To get three problem free recording for an hour, I also had to
double the diskwriter's RingBuffer size, and cut it's write size in half.

My latest "tuning" has to do with how long the hdtvrecorder ringbuffer
sleeps per cycle.  If it sleeps too long, I get overruns.  If it does not
sleep long enough, I get "IOBOUNDs" which lead to the ringbuffer filling up.

I have decided that if the ringbuffer gets over 85% full, that it is better
to drop a chunk of data on the floor, than have perpetual overruns until
the show is over.  Still playing with that...


> Regards.
>
> -Eric


I look forward to working with you on this project.


John


More information about the mythtv-dev mailing list