Preparing 720p H.264 content for a (very) old PC

[gamebox]

Hello to all of you who feed me with precious piece of advice about my current favorite and big inspiration - the H.264 codec. :) With your help I'm building a very high level of quality in my medium/low bitrate encodings.

Now I need an advice about something most of you might find strange, but nevermind. :) What's it about - I have a very old, very slow computer whose specs aren't enough for (HighDef) H264 playback. Namely, it's an Athlon 2400+ CPU @ 2GHz but on an old motherboard with 1GB of SDRAM (100 MHz). I plan to encode some 720p content specifically for it, using simple enough options so he can play it back without overloading the CPU or skipping frames. I tried switching off the CABAC (as I know it's computationally intensive) and lowering ref. frame count to 3, but it didn't help - CPU load was still 100% although it was played without disturbing stuttering. What more can I do here? The system has no issues playing H.263 720p content, and reaches about 60-75% CPU load in the process, but I want it to play (simplified) H.264 to get somewhat sharper and cleaner image. The main limiting factor is, most probably, memory bandwidth rather than the CPU itself, so I want to keep video buffer's size low (as on H.263). Should I lower ref. frames count to 1, encode without B-frames at all, or something else? Thanks for any useful information on this. :)

[sneaker_ger]

--tune fastdecode (--no-cabac --no-deblock --no-weightb --weightp 0). Reduce resolution. Number of b or ref frames don't make a big impact AFAIK.
Try different decoders (CoreAVC was pretty fast on some older systems)

[gamebox]

Thanks sneaker_ger. :) I use Avidemux 2.6.8 to encode on my main system, as I still use Windows XP 32-bit. I haven't been able to find --tune fastdecode setting here, but will manually turn off Weighted B-frame prediction and Loop filter besides CABAC. Is --weightp 0 the same as "DCT decimation on P-frames"?

The number of reference or B frames perhaps doesn't influence CPU load that much, but my main challenge is to keep RAM use (buffer size and changes in it) at the minimum as RAM's speed and bandwidth are far below CPU's capabilities and requirements. A typical 720p H.263 video has a very small playback buffer compared to H.264.

[sneaker_ger]

Is --weightp 0 the same as "DCT decimation on P-frames"?
No, it's weighted prediction for p frames. The weighted prediction for b frames is directly below it. Disable both.

[gamebox]

Found it - it's a drop down menu. :) Will test with those options later on, my main system is busy for the rest of the day doing some "regular" 720p encoding - preset veryslow basically.

[kuchikirukia]

I'd say something's wrong with your decoder/player since I could play 720p60 just fine on my X2 5200+ with MPC-HC and madVR.

[littleD]

I have some experience with such an old computers. That athlon should decode 720p just fine so no need to special tuning of your encodes. There are two concerns anyway. IIRC RAM should be clocked at 133mhz for better performance overall. But what might also impact playback in your case is video ram. What is your graphic card anyway? For Full HD playback vRAM should be 256MB, for 720p might be bit lower, if your GPU have shared memory, increase its size in BIOS.
For decoder i would go for the latest lavfilters and a player MPC-HC set for vmr9 renderer.

[mariush]

On my old IBM Thinkpad T40 laptop (with a Centrino 1.5ghz cpu and radeon video card with minimal video acceleration) I found old versions of CoreAVC quite faster compared to the built in codecs of MPC-HC. It played 720x480 h264 videos with about 40-60% cpu usage. Not sure if such antique would play 720p fluidly, but an athlon should be even faster.

[gamebox]

@kuchikirukia, mariush: Nothing's wrong with my decoder/CPU, it's just a PC based on a 2001 motherboard with SDRAM of only 100 MHz.

@littleD: Yeah, Athlon XP 2400+ is a decent CPU, but here it's (very) limited with the speed of RAM. I tried clocking it to 133 MHz (all 3 modules are PC-133 anyway), but it just wouldn't boot. Best I could do is to "overclock" it to 108 or 109, and that's where the limit was (although mobo manual did state it was bringing "evolutionary 133 MHz support"). I think chipset might be to blame, as even magazines and websites introducing the motherboard at the time weren't able to get reliable information whether it was supposed to do 133 MHz or not, and it wasn't certain even if it was a desktop or laptop chipset in the first place. The mobo is Abit's KT7E.
Video card is GeForce4 MX440 with 64MB DDR. Are you sure GPU's memory size affects decoding - it's still done in software and CPU/RAM? H.263 720p videos play fine without overloading the CPU.
I'll give different decoders a try. MPC-HC was set to Overlay I think, H.264 decoder was FFDShow from mid-2014.

[littleD]

@kuchikirukia, mariush: Nothing's wrong with my decoder/CPU, it's just a PC based on a 2001 motherboard with SDRAM of only 100 MHz.

@littleD: Yeah, Athlon XP 2400+ is a decent CPU, but here it's (very) limited with the speed of RAM. I tried clocking it to 133 MHz (all 3 modules are PC-133 anyway), but it just wouldn't boot. Best I could do is to "overclock" it to 108 or 109, and that's where the limit was (although mobo manual did state it was bringing "evolutionary 133 MHz support"). I think chipset might be to blame, as even magazines and websites introducing the motherboard at the time weren't able to get reliable information whether it was supposed to do 133 MHz or not, and it wasn't certain even if it was a desktop or laptop chipset in the first place. The mobo is Abit's KT7E.
Video card is GeForce4 MX440 with 64MB DDR. Are you sure GPU's memory size affects decoding - it's still done in software and CPU/RAM? H.263 720p videos play fine without overloading the CPU.
I'll give different decoders a try. MPC-HC was set to Overlay I think, H.264 decoder was FFDShow from mid-2014.


HI again. You suspect right, unfortunaletly. It is the chipset to blame. The (cheaper) chipset operates in 100Mhz (FSB) frequency for CPU and 133Mhz for memory bus (RAM). This is what we can deduct from manual, but is confirmed on wikipedia.
Now the tricky part. Usually cpus from Athlon XP era should have same FSB frequency as RAM frequency. This is golden rule for that setup. If you change RAM only (not fsb) to 133HZ (DRAM CLK option - HCLK+PCICLK) this may increase or even slowdown your rig. Be careful because other adjustments may needed like latency or other. But what really bug me is how your CPU works in 100Mhz mode, since it normally operates in 133Mhz. Isnt your CPU's power crippled? Lets read some data from cpu-z tool program, if it reallly shows 2Ghz. Additionally, manual doesnt say Mobo supports athlon XP, so i believe Athlon is not at its full potential.

By the time being in BIOS, you can turn off/disable any power management features but enable/turn on AGPx4, Fast Write, Enchance Chip performance.

Advice to increase sharable video RAm size on laptops helped many people. Since you have desktop there is no sharable memory so i would really try with 128MB Aperture size option.

And finally, ffdshow from last year consider depreciated, because noone updates this project right now. The latest speed patches are in lavfilters, give it a try.

[gamebox]

@LittleD: Thanks for the info. :)
I wanted to try setting the BIOS again immediately, but I remembered there is no free (fourth!) keyboard tonight - it will have to wait a bit. :)
I think I tried raising the RAM speed above CPU FSB but still couldn't go over 108-109 MHz, though I'll test again. Athlon XP 2400+ isn't officially supported by the mobo, but I happened to find a BIOS some enthusiast wrote and gave it a try. On the first run it sets the CPU at 20x100, and that's where it still is. You can't do much else anyway - the system gets locked if you try 133 MHz, and for the multiplier you only have an option, "13 and above" or so - that one has been "added" to BIOS. Very high MHz count means little here - CPU can easily get loaded to 100% even when doing tasks that require 20% of it's processing ability if they require a lot of RAM. Even my original Duron 1200 was severely slowed down while encoding using memory-intensive video filters like denoise.

Apart from BIOS settings, I will probably not be changing anything in hardware (requiring any investment). That's my old system which I kept after upgrade, but the reality is I don't need it anymore. It can not, by any means, be an useful encoding rig (I have P4 2.4, A64 3500+ and Sempron 140 for that), and it's ability to play back H264 means little to me now that I've even got an H264 SetTopBox. This tweaking to get 720p from it is it's preparation for a better home (one where it's presence would make some difference).

LavFilters...I think I have them and will try them too. I put them aside ever since video decoding in my system was offloaded to a GPU. I think the ones I have worked with Windows XP 32-bit all my computers use.

[F J Walter]

If disabling CABAC and deblock isn't enough, you may have to consider either resampling to a lower resolution or using a simpler codec (MPEG-4 ASP?)

If you put a value on your time, the cheapest option often works out to be a hardware upgrade.

[gamebox]

Today was the testing day, as both of my "auxiliary encoding machines" - the Athlon64 and Pentium 4 - were automatically put to hibernation in the morning after encoding through the night, and I had a keyboard to spare. :)

LittleD was right, RAM can be set to 133 MHz while CPU's FSB remains at 100 - thanks a lot! :) It was an option "CPU FSB+PCI CLK" or something like it. It made an appreciable difference, so eventually H.264 encoded 720p material was playable pretty smoothly. CPU load was 90-100% for video with no CABAC, and constantly 100% but still smooth if CABAC was used. Decoder was still FFDShow from June 2014, as newest LAV filters spew out some errors involving system libraries during installation and refused to load. I guess Windows XP 32-bit is not supported. I left "Output" in MPC-HC at "Overlay" as VMR9 renderer introduced some tearing.

This is already a big improvement, so if older LAV filters bring CPU load below 100% when using CABAC, I won't ask for more. :)

[kuchikirukia]

Decoder was still FFDShow from June 2014, as newest LAV filters spew out some errors involving system libraries during installation and refused to load. I guess Windows XP 32-bit is not supported. I left "Output" in MPC-HC at "Overlay" as VMR9 renderer introduced some tearing.

This is already a big improvement, so if older LAV filters bring CPU load below 100% when using CABAC, I won't ask for more. :)

I was just on XP 32 bit a couple months ago with LAV 0.63.

And madVR can decrease CPU util by offloading some to the GPU. Not sure if it can use a Geforce 4, though, but try it with bilinear.

[gamebox]

Oh, I went for the latest stable build - I think 0.66 or so. :( GeForce4 has no video decoding capabilities whatsoever, but might help with resizing or some similar phases during playback, who knows. Might try that tomorrow, no free keyboard again right now as all my systems are busy encoding.

[littleD]

Hey, its nice we see some improvements. But really, i believe athlon @2Ghz should have usage of 60-70%

When it comes to missing libraries for lav, lav filter by default is compiled for vs2015, so you would need to download x86 redistributables of Visual Studio 2015 from Microsoft site. Xp is not supported by MS anymore, so if vs 2015 is not gonna install on this system, just download one stable version of lav before 0.66. Also make sure you have WIn XP SP3 already installed, many todays applications require this.

And i already told about BIOS settings, but i encourage you to try 128MB AGP aperture setting. It no harm your computer, but we can try-and-see if that improves things too.

[gamebox]

@LittleD: I would also like to see CPU usage of about 60% for Athlon XP @ 2GHz while decoding 720p, but I don't expect it with SDRAM. SDRAM has a habit of making simple tasks about 2-3 times slower and lengthier compared to a similar system with DDR (typical example being RAR compression for instance). And I remember my previous Athlon64 @ 2.2GHz had about 60% load decoding regular 720p H.264, and that was with DDR RAM at 400 MHz.

AGP aperture set to 128 MB, and AGP-4x enabled in previous test.

Windows XP SP3 might be an issue, as I happened to have some "light" version of WinXP Professional with most of unnecessary components removed (installation weighs less than 200 MB) and that system uses less than 100 MB RAM running, but comes without SP3 (and I think I had no luck installing it once because the OS is basically incomplete). Lav had issues with Kernel32.dll. I might install "full" XP Pro, but that will have to wait some time.

[manolito]

When it comes to missing libraries for lav, lav filter by default is compiled for vs2015, so you would need to download x86 redistributables of Visual Studio 2015 from Microsoft site.

In my experience this is not true... :p

I have WinXP Pro SP3 installed, and the VC++ redistributables on my machine are 2005, 2008 and 2010.

LAV Filters 0.66 run without any issues here.


Cheers
manolito