[mythtv] Patch for "fixme" in NuppelVideoRecorder.cpp

[mythtv-dev@snowman.net]

On Fri, 15 Nov 2002, Isaac Richards wrote:

> Unfortunately, this won't work as you'd think -- the two modifications to the 
> counter you added happen in different threads.  And, especially the 
> modification to the counter in BufferIt() has the possibility of swapping to 
> the thread that's doing the doWriteThread() in between the two changes.  So, 
> to do this properly, you'd have to lock down all access to that variable, and 
> that'd probably take more time than the current iteration through all 
> available buffers to count which are in use or not.

Rats!  It would probably be quicker to just iterate through the buffers 
each time than start locking with ever access.

> 
> > Also, in what case(s) is it necessary to have the thread for writing
> > data to the disk (ThreadedFileWriter)?  The implementation is a ring
> > buffer that has data added when Write() is called, then sending that
> > data to the disk in another thread.  Doesn't the write() system call
> > just dump the data to kernel buffers, where it is written when it can
> > be?  The extra thread and memcpy's to implement the ring buffer stuff
> > may not be necessary.  I didn't notice any difference in performance
> > when I removed all of the ThreadedFileWriter code and just had system
> > write() calls.
> 
> It's useful for when you've got a slower disk and are using the rtjpeg codec.  
> If for some reason, there's a period of heavier disk usage caused by 
> something else on the system, and the recorded starts running out of free 
> video buffers, it used to just assume that that was because of a temporary 
> lack of CPU, and decide not to compress a frame in order to save a little CPU 
> time.   If it _was_ due to a lack of disk transfer capacity instead, that'd 
> just make the problem worse.  With the ThreadedFileWriter class, it can know 
> how full the buffers to write to disk are, and force compression of a frame 
> in that case.

Hmmm..  So if someone has a system with a fast hard drive, lots of memory,
and it's dedicated to this task, they wouldn't need the extra thread.  
But those people are the ones that wouldn't notice any slowdown anyway,
from the overhead of the extra thread.