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

Isaac Richards mythtv-dev@snowman.net
Fri, 15 Nov 2002 13:15:22 -0500


On Friday 15 November 2002 10:53 am, rob wrote:
> Here's a patch to fix the block of code in NuppelVideoRecorder.cpp that
> has the comment "count free buffers -- FIXME this can be done with less
> CPU time!!"  It just adds a member variable to the class that keeps
> track of the free buffers, instead of counting them in the loop every
> time in the function.

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.

> 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.

Isaac