View Full Version : Getting an handle on CPU requirement for h264 playback
Zag
16th February 2006, 15:37
Just started getting my feet wet with h264. Using MeGUI, I have compressed some High Def recordings. Trying to maximize quality, I left the resolution at 1280x720 and left the bitrate up to the encoder by just specifing a size of 4400 MB. I used the HQ-Slow profile and about 20 hours later (using a dual core opteron @2.4GHz does the encoding time sound right?) I had very nice results which played fine on the dual core opteron.
Playing it back on my HTPC is another story. My HTPC is an athlon XP 3200+ with an ATI9600XT video card, using CoreAVC as my decoder both zoomplayer and MPC I had 100% cpu utilization with frame skipping and sound lagging behind video. Using TMPCP the video played fine with cpu utilization around 50-70%.
I have played other movies with lower resolution and/or lower bitrate and have not had any issues with playback using either zoomplayer or MPC.
Why is that TCPMP can play the movie much better that MPC/zoomplayer with CoreAVC? I was under the impression that TCPMP avc decoder is derived from coreavc. I would use TMPCP but it does not support 5.1.
If this is the way it is I will have to rethink my strategy for High Def h264 compression. Anybody have any recommendation on resolution and bitrate to use for high def recordings? I am not as concerned with size (just want to keep it under DVDR size per movie) as I am with quality. I am however concerned with playback since I won't be upgrading my HTPC cpu anytime soon.
Daodan
16th February 2006, 16:42
First of all welcome. Secondly, 20 hours is small time (just to make a comparison on my dual opteron (1.8 though), a 3 hours movie takes 1 week), probably you don't use much filtering. For a 1.5-2 hours movie that size (1 DVD) is very good, basically something around 4 mbps will give very good results. Of course it's recommended to crop any black borders the movie may have (they usually do), that will decrease the encoding time, playback requirements, and imporve image quality. As for playback there is something definitely wrong, I have also a Venice 3200+ that plays fine (about 55%) such encodes. So make sure you actually use CoreAVC as a filter, maybe you have some other filter with higher priority (even though FFDShow for example plays also fine if postprocessing is disabled).
Zag
17th February 2006, 21:08
Thanks for the welcome, this seems to be a great place with lots of good info.
Wow I didn't relize that compression would be that time consuming, as far as filtering, I used the HQ-Slow profile written by sharktooth, does that apply any filtering or is that something I would need to add manually? I did crop the black borders but most of my recordings are 1.78 AR so no bars are present. So you say 4 mbps is a good compromise, I'll have to start using that.
Playback is still an issue. I am definately using CoreAVC (as shown in directshow filters in zoomplayer and MPC), for audio I am using FFDShow but I wouldn't think that would make any difference. I am just amazed that TCPMP can play these movies using 50-70% cpu while mpc/coreavc pegs my CPU, I even tried Mplayer but that is even worse. I guess I'll just have to either upgrade (not likely since socket A is dead) or decrease bitrate/resolution. Once again thanks for your help.
Daodan
20th February 2006, 15:58
Decreasing bitrate won't help you. Upgrade is not recommended actually, I think that's still a quite good cpu you have there. Just to check I sent a friend with xp 2100+ a sample of my encodes (1280*680) and it plays fine with coreAVC, so there is somthing wrong with your settings. I found a strange *bug* that when using vsfilter together with an external sub with mpc, haali splitter and FFDShow, the file plays very badly, the cpu is at 100% (but not when embedded). Tell me how this sample works on your computer: http://savefile.com/projects/443511
Zag
20th February 2006, 23:58
When playing the sample using MPC/CoreAVC/CoreAAC the cpu usage is around 95-100% with a couple of times studdering and audio loss for a split second. Didn't seem to matter if I had the subtitles showing or not altough haali splitter gives me a warning about the video containing true type fonts. When playing the sample with TCPMP the cpu usage is around 40-60% and it plays very smoothly. Using zoomplayer/CoreAVC/FFDShowaudio, it is about the same as MPC maybe just a bit worse. Mplayer is the worst but it uses FFMPEG for decoding.
You say that decreasing bitrate won't help but I can play videos encoded with bitrates between 1200-1600 without any problems (resolutions are also smaller 720x408). It's the higher resolution/bitrates that I can't play smoothly. I just finished encoding an HD movie using megui at 1280x544 with bitrate set at 4400 HQ-slow profile and I can't play it smoothly on that machine. I am also having problem with the audio getting out of sync as the movie progresses (although I didn't compress it, left it as AC3) but that's another issue and I will have to read up on it.
Daodan
21st February 2006, 10:31
Audio desync is normal if your CPU is 100%, it's because the audio plays fine but the video is played slower than normal, so it seems that the audio is going ahead of the video. 1280x720=921600 pixels per frame, 720x408=293760 pixels per frame, so 3 times less, obviously more power is needed. And trust me, bitrate has no influence here (unless of course it is very high bitrate, something above 20 mbps, in which case you can blame it on the harddisk, but it's not the case). As for your playback problem, I have no idea what the problem is, maybe a clean install of windows together with installing only very few filters that you know they work fine, that's all I can think of now..as I said, something is wrong on your side. Since TCPMP plays fine and uses CoreAVC clearly something interferes with the coreAVC version for directshow. Maybe you have a weird version or something, try this one:
http://81.98.148.105/Uploaded_Files/Doom9_Forum_files/CoreAVC_DSDec.zip
Zag
21st February 2006, 17:33
Thanks for all your help, I have got a couple of other systems that I'll try it on and see how things turn out.
I should have been more specific on the audio sync issue. I have a separate system that I use for encoding and testing. It is a dual core opteron running @2.4Ghz. This system is powerfull enough for playback but it is showing me that the movie has audio sync issues.
The playback issue that we were discussing is on my HTPC connected to my TV and it only has a XP 3200+. Sorry about the confusion.
Taurus
21st February 2006, 18:37
@Zag
Just made some tests on my old AMD Athlon XP 2200+:
Using MPC/CoreAVC/CoreAAC I can go up to 1920x1080 avc+aac audio in mp4 container.
The sample provided by Daodan works like a charme.
So there is definetely aomething burked on your side.
Did you register the coreavc.ax in the right way? And don't move this file after registration.
Maybe take a look into Graphedit and render your file there. It should only be connected to Haali's Splitter, coreavc, coreaac, Video Renderer, Audio Renderer (Direct Sound Device) for example.
Cheers
Taurus
Zorrander
27th February 2006, 21:51
I've had similar problems with haali splitter, vsfilter, ffdshow maxing out the CPU where normal h264 items I encode in Mencoder will run the CPU around 60%. The only thing I noticed unusual is ffdshow shows the video FOURCC as avc1 when all the stuff I encode has a FOURCC of h264. I'm not aware of the differences... but apparently ffdshow and coreavc handle these way differently.
Side note - I've been using MPC for a long time and tried the CoreAVC decoder with about 90% success. The only files I've had problems with are some episodes of Gundam Seed that ended up encoding to 25fps. THe audio and video will run fine for a bit, then suddently the audio falls behind about half a second for no reason. I don't hear any slowdown in the audio or notice lag in the video... so I tried using ffdshow's h264 decoder and that works fine. Hopefully the release version of CoreAVC will be more reliable. Until then I don't use coreavc since my computer handles files fine with ffdshow
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.