[mythtv-users] Digital Pegs CPU

[Paulin]

On Wed, Nov 26, 2008 at 11:58 PM, Rod Smith <mythtv at rodsbooks.com> wrote:

> 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<ranma%2Bmplayer 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
>

Well I ran your script (Thank for that) and got the following on the
two different recording types.

H1250 (Digital)
size: 4669085696

ID_VIDEO_ID=0
ID_AUDIO_ID=0
ID_FILENAME=2007_20081123200000.mpg
ID_DEMUXER=mpegps
ID_VIDEO_FORMAT=0x10000002
ID_VIDEO_BITRATE=6000000
ID_VIDEO_WIDTH=720
ID_VIDEO_HEIGHT=480
ID_VIDEO_FPS=29.970
ID_VIDEO_ASPECT=0.0000
ID_AUDIO_FORMAT=80
ID_AUDIO_BITRATE=0
ID_AUDIO_RATE=0
ID_AUDIO_NCH=0
ID_LENGTH=7197.39
ID_VIDEO_CODEC=mpegpes
ID_AUDIO_BITRATE=384000
ID_AUDIO_RATE=48000
ID_AUDIO_NCH=2
ID_AUDIO_CODEC=mad

H250 (Analog)
size: 2333061120

ID_VIDEO_ID=0
ID_AUDIO_ID=0
ID_FILENAME=2033_20081127070000.mpg
ID_DEMUXER=mpegps
ID_VIDEO_FORMAT=0x10000002
ID_VIDEO_BITRATE=6000000
ID_VIDEO_WIDTH=720
ID_VIDEO_HEIGHT=480
ID_VIDEO_FPS=29.970
ID_VIDEO_ASPECT=0.0000
ID_AUDIO_FORMAT=80
ID_AUDIO_BITRATE=0
ID_AUDIO_RATE=0
ID_AUDIO_NCH=0
ID_LENGTH=3595.59
ID_VIDEO_CODEC=mpegpes
ID_AUDIO_BITRATE=384000
ID_AUDIO_RATE=48000
ID_AUDIO_NCH=2
ID_AUDIO_CODEC=mad

Do any of the help?

Also I found out that MiniMyth (which is what I'm using on the VIA board)
has XvMC built in support.  I had it enabled.  I also tried XvMC-VLD.  So
based on earlier discussion I believe (but I could defiantly be wrong) that
the XvMC support isn't the problem.

Now I did have Deinterlace set to bobdeint.  There are a host to choose
from.  Not sure what I should be using here.  Any recommendations.

Thanks and I really appreciate all of the help.  Hopefully this will start
making sense soon.

steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20081127/b584874a/attachment.htm