[mythtv-users] Digital Pegs CPU

Rod Smith mythtv at rodsbooks.com
Thu Nov 27 04:58:34 UTC 2008


On Wednesday 26 November 2008 05:01:15 pm Paulin wrote:
>
> And I'm sorry if I'm not explaining things properly.  A lot of this is very
> new to me and I'm still trying to learn.
>
> As for my Digital/Analog.  Basically I have Comcast who is sending the
> analog and digital over the line.  I have two cards.  The PVR250 recording
> the analog channels from Comcast.  Then I have a HVR1250 getting the
> Comcast digital channels.   I did realize they are all become MPEG files
> and I would guess the digital is MPEG4 while the PVR is doing MPEG2 (but
> that is a guess).

The PVR-250 definitely delivers MPEG-2 files. I don't use the HVR-1250, but 
based on the description on the MythTV wiki, it appears to be a simple 
digital (ATSC/QAM) capture card (with analog NTSC support in the hardware but 
not yet in the Linux drivers). As such, channels tuned with this card will 
also produce MPEG-2 files. Depending on the channels tuned and the MythTV 
settings for recording from the PVR-250, the digital channels could result in 
files that are smaller than, the same size as, or bigger than files from the 
PVR-250 (for recordings of identical length in time).

> I figured the digital recordings are just bigger (bit rate/resolution)
> which is accounting for the problem.  So with that how can I adjust that.

You may be right, but unfortunately, there's no way to adjust the size of 
recordings from digital sources -- at least, not directly. A digital tuner 
card just takes the bitstream as delivered by the TV station or cable company 
and dumps that bitstream into a file. Any resolution or other size 
adjustments must be done after the fact. In MythTV, you'd do this with 
transcoding, which will of course take a lot of time and also convert from 
MPEG-2 to another format (probably MPEG-4).

You can learn about your files' formats using the midentify command (see note 
below):

$ midentify 4049_20081126195800.mpg

You'll see a bunch of output. Pay attention to the following lines:

ID_VIDEO_WIDTH=640
ID_VIDEO_HEIGHT=480
ID_VIDEO_FPS=29.970
ID_VIDEO_CODEC=mpegpes

The video width and height show the resolution of the recording, and the fps 
is the frames per second. You'll need to track down the files at a Linux 
command prompt to do this, of course. By default, MythTV names files using 
the tuner source and channel (4049 in this example), then the date and time 
(20081126195800 -- Nov. 26, 2008 at 19:58:00). Thus, you can easily find the 
right recording by searching on the date (and perhaps time):

$ ls -lh *11261958*
-rw-r--r-- 1 mythtv mythtv 2.4G 2008-11-26 21:03 4049_20081126195800.mpg
-rw-rw-rw- 1 mythtv mythtv 123K 2008-11-26 21:03 4049_20081126195800.mpg.png

Once you do the identification, you'll know how your PVR-250 is storing files 
(the values should match whatever you set up in MythTV) vs. what you're 
getting for the digital channels. If your digital channels are coming in at 
substantially higher resolution (say, 1280x720 or above), then you're 
recording HDTV. If you're watching this on an SD TV set, you might want to 
see if you can find equivalent digital SD channels on your cable lineup. If 
that fails, you may be able to tune such channels over the air (OTA) rather 
than via the cable system.

A simpler way to identify your recordings, but one that provides less 
information, is to check the file size. You can do this from the MythTV 
interface. Depending on your settings, analog channels will probably clock in 
at between 0.5GB to 3GB per hour, but they could fall outside this range if 
you've set extreme bitrate values. On my system (using Cox cable in RI), HD 
digital channels consume about 6-8GB per hour. The only SD digital channels 
I'm getting right now are useless (TV guide and the like), but at one time I 
got an SD digital version of CBS. IIRC, it clocked in at about 1.5GB per 
hour. Your cable company can set its bitrates as it sees fit, so your figures 
may not exactly match these.

A note about midentify: On my system, this is a script that calls mplayer with 
various options. If you don't have such a script, here's mine:

#!/bin/sh
#
# This is a wrapper around the -identify functionality.
# It is supposed to escape the output properly, so it can be easily
# used in shellscripts by 'eval'ing the output of this script.
#
# Written by Tobias Diedrich <ranma+mplayer at tdiedrich.de>
# Licensed under GNU GPL.

if [ -z "$1" ]; then
        echo "Usage: midentify <file> [<file> ...]"
        exit 1
fi

mplayer -vo null -ao null -frames 0 -identify "$@" 2>/dev/null |
        sed -ne '/^ID_/ {
                          s/[]()|&;<>'"'"'\\!$" []/\\&/g;p
                         }'

> Second I know that the M10000 board has an MPEG decoder, so I'm surprised
> the CPU is hit as much for playback.  Or is it being hit for the data
> transmission (streaming) that is causing the problem.

As I understand it, most video devices for Linux support, at best, only *HELP* 
for MPEG-2 decoding -- they can accelerate the process, but a good deal of 
number-crunching is still left to the CPU. Certainly this is true on my own 
system, which has an nVidia  FX5200 card and Intel Celeron-D 3GHz CPU. From 
memory, CPU load is in the 5-10% range when playing back SD video, but in the 
50-70% range when playing back HD video. When misconfigured, I get 100% CPU 
use and stuttering playback when playing HD content. Thus, I'm skeptical that 
your 1GHz CPU could handle HD content.

That said, I'm unfamiliar with your motherboard. A quick Google search 
suggests it's got a VIA chipset with integrated video and VIA's C3 CPU. I 
don't know what video drivers you're using (or should be using) or how well 
all this works under Linux. It's conceivable that your setup has better 
MPEG-2 support in the video drivers and hardware than nVidia's drivers 
provide with my FX5200 card, and/or that the C3 CPU does more work per CPU 
cycle than my Celeron-D. If so, you might be able to handle HD content, but I 
expect you'll be close to the edge at best.

-- 
Rod Smith


More information about the mythtv-users mailing list