Mailing List Archive

I could be way off base here, but wouldn't a MPEG4 Variable Bit Rate
real time encoder always use 100% of available processor. The way I
understand it is that the encoder is trying to compress the video in
real time as much as it possibly can thus using all of the available
clock cycles. If you look at the file sizes of files encoded with the
frontend off vs with the front end on, you should notice a significant
difference in the amount of disk space consumed for a given length of
video. In otherwords... your cpu runs at max capacity when encoding and
depending upon how many cycles are used by other processes the level of
compression will vary.

I hope this makes sense, it's late and I'm tired... but as far as I
understand it this is the way most realtime VBR encoders work. Or isn't
the MPEG4 encoder VBR?

Joe

-----Original Message-----
From: mythtv-users-bounces@snowman.net
[mailto:mythtv-users-bounces@snowman.net] On Behalf Of Wally Wallace
Sent: Wednesday, April 09, 2003 11:12 PM
To: mythtv-users@snowman.net
Subject: [mythtv-users] mythbackend is fricking frying my cpu

I am running the latest cvs.
My system:
athlon 2100+ overclocked to 2.1ghz
512mb ddr ram
geforce2mx
asus a7v266 board
wd 200gb 8mb cache drive
hdparm -tT gives 270/51
wintv 401 (i think - bought used) with btaudio working for digital and
analog
avertv stereo (btaudio only for analog which sucks)
onboard cmedia sound
soundblaster live (when i try to capture the line in is noisy as hell!)

Using btaudio with my wintv card I tried to record 3 episodes of that
70's show tonight. I wasn't running the frontend. Top showed 95-100% cpu
usage! My settings are mpeg4 640x480, 3300, 2, 15, 3 and scale bitrate.
Audio quality is 44100 and 7.
I know my system should handle this!!!! I specced it specifially to do
high quality recording. I will overclock my cpu even more when I get a
better hs/fan.
It seems like mpeg4 is totally fubared for my, rtjpeg works, but I built
the system for mpeg4 cause i want good quality recordings. Same settings
with rtjpeg gives me 60-70% cpu which is also too friggin high. The
worst part is, when I do live tv with the same setting cpu usage is at
100% for mpeg4, but backend is only 70-80 and frontend takes the rest.
Now that makes no since, cause in record only backend takes all my cpu!

So i can view those mpeg4 recordings, and they look beautiful but
audio/bisual is way messed up and i get constant -
Audio buffer overflow, audio data lost!
The video is rushed too, by like 20-30% so peoples lips move really
fast.

Next problem:
I get a very annoying poping sound whenever i change channels. Channel
changing also takes at least 500ms.

Next problem:
Every time I change channels I get frame drops for like the first
5-10seconds then it smooths out. This happens with mpeg4 of any
reasonable setting but not on rtjpeg.

Next problem:
I hit v for pip and my audio gets very choppy and drops every other
frame. This seems to just happen with rtjpeg!

Next problem:
The ringbuffer seems to work for rtjpeg but not mpeg4
I can only rewind in rtjpeg, mpeg4 says it is recording but only goes
back 3 secs.

So should i even bother with mpeg4? Everyone seems to say
it is better, and like i said, my out of sync high cpu recordings are
beautiful. My system should handle that right? Especially in backend
only mode.

I just did some more tests. Even 480x480 mpeg4 uses all my cpu and
gives me:
Audio buffer overflow, audio data lost!
This also happened when viewing the mpeg4 recordings.

Thanks for any insight.
_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

> Top showed 95-100% cpu

> The video is rushed too, by like 20-30% so peoples lips move really
> fast.

This sounds somewhat like you may not have DMA enabled for your HD?

Do: hdparm /dev/hda and see what it says

> I could be way off base here, but wouldn't a MPEG4 Variable Bit Rate
> real time encoder always use 100% of available processor. The way I
> understand it is that the encoder is trying to compress the video in
> real time as much as it possibly can thus using all of the available
> clock cycles.

The variable word in variable bit rate simply refers to the fact that the average bit rate of the video is fairly constant, however, the bit rate used for particular scenes can vary. In this way you lower the bit rate of the encoder on easy static scenes, and crank it up on fast moving scenes.

Overall quality is much higher in general, but the average bit rate is still reasonable.

>>>>> On Wed, 9 Apr 2003 22:12:09 -0500, Wally Wallace <wally@satx.rr.com> said:

w> I am running the latest cvs.
w> My system:
w> athlon 2100+ overclocked to 2.1ghz
w> 512mb ddr ram
w> geforce2mx
w> asus a7v266 board
w> wd 200gb 8mb cache drive
w> hdparm -tT gives 270/51

[...]

w> Using btaudio with my wintv card I tried to record 3 episodes of that
w> 70's show tonight. I wasn't running the frontend. Top showed 95-100% cpu
w> usage! My settings are mpeg4 640x480, 3300, 2, 15, 3 and scale bitrate.
w> Audio quality is 44100 and 7.


Did you happen to change any compilation flags when you ran
"configure"? (You shouldn't have to.) Did you turn on mpeg4 4mv
encoding? (I think your system should just be able to handle it but
maybe you can see if turning it off makes a difference.)

--
Gregorio Gervasio, Jr.
gtgj@pacbell.net

Note this email is largely a "me too" email. :)

On Wed, 2003-04-09 at 23:12, Wally Wallace wrote:
> I am running the latest cvs.

Me too, and I find it _really_ unstable. I hope all the stability
problems I'm having are known and will be ironed out and that it's not
all just me. :)

> My system:

Mine is an Athlon 1400, 768M, GF2MX, 80G Seagate ST380020A (hdparm -tT:
232.7/22.5), WinTV PCI, SB Live. using_dma, unmaskirq, and 32-bit IO.

> soundblaster live (when i try to capture the line in is noisy as hell!)

My line-in captures nicely.

> 70's show tonight. I wasn't running the frontend. Top showed 95-100% cpu
> usage! My settings are mpeg4 640x480, 3300, 2, 15, 3 and scale bitrate.
> Audio quality is 44100 and 7.

My settings are mpeg4, 640x480, 2200, max quality: 1, min quality: 3,
quality between frames: 2, audio is uncompressed at 44100. When
recording my processor is anywhere from 50% to 85%. This is with
mythfrontend not loaded (i.e. not watching any video). vhq and v4mv
settings disabled since my cpu can't keep up with them.

> It seems like mpeg4 is totally fubared for my, rtjpeg works, but I built
> the system for mpeg4 cause i want good quality recordings. Same settings

This is a bit tangential, but I find even at the highest quality setting
RTjpeg yields poor quality. Certainly I know jpeg is capable of
better. Is there any tweaks one can do to improve this? Or is mpeg4
the way to go for encoding?

> Every time I change channels I get frame drops for like the first
> 5-10seconds then it smooths out. This happens with mpeg4 of any
> reasonable setting but not on rtjpeg.

A resounding "me too" on this one. At first I thought it had to do with
the small cache on my harddisk (2MB) but your disk is much more
impressive than mine and you're still seeing the problem.

Anyone have any ideas?

> The ringbuffer seems to work for rtjpeg but not mpeg4
> I can only rewind in rtjpeg, mpeg4 says it is recording but only goes
> back 3 secs.

Mine appears to work.

> So should i even bother with mpeg4? Everyone seems to say
> it is better, and like i said, my out of sync high cpu recordings are
> beautiful. My system should handle that right? Especially in backend
> only mode.

I think mpeg4 is the _only_ way to go, based on the quality I've seen
from RTjpeg. Perhaps the developers just need some more time to work
out the kinks? I'm curious to hear other people's experiences.

On another note, MythTV docs say that the processor must support SSE in
order to do deinterlacing. According to /proc/cpuinfo, my Athlon
doesn't do SSE, yet deinterlacing works fine for me. Are the docs out
of date?

Jason.

> soundblaster live (when i try to capture the line in is noisy as hell!)

Try muting the mic input (assuming that you are using the line-in)

> I am running the latest cvs.
> My system:
> athlon 2100+ overclocked to 2.1ghz
> 512mb ddr ram
> geforce2mx
> asus a7v266 board
> wd 200gb 8mb cache drive
> hdparm -tT gives 270/51
> wintv 401 (i think - bought used) with btaudio working for digital and
> analog
> avertv stereo (btaudio only for analog which sucks)
> onboard cmedia sound
> soundblaster live (when i try to capture the line in is noisy as hell!)

So I have the same CPU, but running at stock speed. I have the same
amount of ram, at 120Gig Seagate (2Meg), and the same capture card. I'm
using my sound card to capture from line in--I don't think that would make
much of a difference, but perhaps sampling from btaudio (if that's what
you're doing) drags down the CPU?

I'm doing 720X480, quality 1->8, 4100 bitrate. MP3 quality is at 9, which
does seem to reduce CPU utlization quite a bit. Normally I sit at around
50-60% CPU utilization, but I enabled both the high quality codec options
the other day, and now sit at around 80-90% utlization (looks at LOT
better, though.)

Here's some stuff you might check out:

DMA for HDDs. Run hdparm and see if you're clocking around 30-40MB/s.
Check that your CPU isn't totally maxxed out when that's going on...it
should spike, but not too badly.

Compile your kernel and MAKE SURE you have the right mainboard drivers
loaded into the kernel. I don't know off the top of my head what chipset
that board uses.

Look in /proc/pci and see what your interrupts are like. You should
probably make sure that your capture card and sound card(s) have their own
IRQ, and nothing else is sharing them. Slots on your board WILL be
sharing IRQs, so find the ones that have a dedicated line and schtick
those two cards in those slots...I think all your other cards will share
IRQs without a problem, and are probably not that critical in the capture
process.

Set your disc staoring video to be ext3, and mount it with the flags
'noatime,data=ordered'. The first doesn't update the atime record when
accessing each inode, the latter is the writeback mode for ext3 which
seems to be the fastest (for me). The noatime option can sometimes really
help--especially when you're talking about liveTV keeping up.

That's all I can think of...I put 'athlon-xp' in the settings.pro file
when making myth, but I doubt that really has that much effect.


> Next problem:
> I get a very annoying poping sound whenever i change channels. Channel
> changing also takes at least 500ms.

That's a known problem with using btaudio as your audio capture. You
might look into using one of your other cards, and definitely (if you're
not) using alsa.

>
>
>My settings are mpeg4, 640x480, 2200, max quality: 1, min quality: 3,
>quality between frames: 2, audio is uncompressed at 44100. When
>recording my processor is anywhere from 50% to 85%. This is with
>mythfrontend not loaded (i.e. not watching any video). vhq and v4mv
>settings disabled since my cpu can't keep up with them.
>
>
>

These are not good settings as far as I can tell. The min/max quality
settings should really only be messed with by experts, and once you get
a feel for the system. I think it might even say something to this
effect in the help text that shows up when those sliders are highlighted
in setup. I don't think the quality settings work exactly like you
think they will work. As I understand it, the primary way for normal
users to affect quality is to change the resolution and bitrate. Try
this: Go back to defaults for your mpeg4 and rtjpeg settings. Give
watching a whirl with the defaults. Then mess with the resolution and
bitrate until you are happy. Then if you insist, work on the min/max
quality settings.

also make sure dma on your HD is set to 1



cedar

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> On another note, MythTV docs say that the processor must
> support SSE in
> order to do deinterlacing. According to /proc/cpuinfo, my Athlon
> doesn't do SSE, yet deinterlacing works fine for me. Are the docs
> out of date?

Please post your /proc/cpuinfo

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPpW2m/c1NpCTlP0JEQI/7ACgumgvNILwozDAk233tG7MKJbGjyQAnRLh
qvDOh/S30vu9f6Em+yeZ5w0V
=T1ux
-----END PGP SIGNATURE-----

On Thu, 2003-04-10 at 14:23, Robert Kulagowski wrote:
> Please post your /proc/cpuinfo

Hi Robert,

processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 4
model name : AMD Athlon(tm) Processor
stepping : 4
cpu MHz : 1400.101
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 2791.83

Cheers,
Jason.

--
Jason Tackaberry :: tack@auc.ca :: 705-949-2301 x330
Academic Computing Support Specialist
Information Technology Services
Algoma University College :: www.auc.ca

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks; according to
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_doc
s/26485A_AthlXPwp_2-10.pdf, AMD's implementation of SSE is within the
"3dnow" instructions. I've updated the HOWTO.


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPpcFufc1NpCTlP0JEQLKTQCfSGD22PohtQIuN8pJcZnbdOi1Va0AoPI7
WH3c07UnSG0/nahdnyAyaIEi
=vPXT
-----END PGP SIGNATURE-----