[mythtv-users] Commercial Detection during recording

Joseph Fry joe at thefrys.com
Mon Mar 11 21:00:38 UTC 2013


>  If so, I wonder if it wouldn't be worthwhile for a patch to adjust the
>> commercial detection job priority to always favor realtime comflagging.
>>
>
> This presumes that I/O is the biggest resource usage of commercial
> detection.  In fact, it's usually CPU usage (for all-software decode of the
> video) that's the biggest resource usage, and I/O is a negligible load in
> comparison.  This is true when recording high-bitrate, high-resolution
> MPEG-2 (such as ATSC) and much more so when recording high-bitrate, high
> resolution AVC/H.264.  This is also true when decoding low-bitrate, low
> resolution (SDTV) MPEG-2 or MPEG-4 with "Auto-commercial-detection jobs
> when recording starts" enabled, because then you're simply decoding a 1hr
> show in 1hr.
>

Mike, CPU is certainly the greatest resource used by comflagging itself...
but there is an IO component to it... and if the IO is already nearly
saturated with concurrent recordings and playback... comflagging may
contribute to playback/recording issues.

Preferring comflagging on current recordings over a FIFO queue achieves 2
advantages:
1. reduction in IO due to caching
2. higher priority recordings can be comflagged before lower priority,
completed recordings.

For example, lets say that one night I record six 1 hour shows, 2 at a time
for 3 hours.  Assume I only have one comflag job defined and my CPU is just
barely fast enough to run realtime.  In this case, when my favorite show
airs in the 3rd hour of recordings, there will be 2 hours of shows left in
the queue before it will get flagged.

This happens to me all the time... there are only a few shows that I want
to watch right away... mostly so friends/coworkers don't spoil them for me
the next day, and they are almost never transcoded when I watch them
because the queue is full of stuff that recorded earlier in the evening.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130311/5a5d23e2/attachment.html>


More information about the mythtv-users mailing list