PDA

View Full Version : Multi-Thread (multi-core) x264 player?


rohan
30th December 2007, 10:48
Here's my challenge:

Playing some x264 content on my system JUST pushes it to the limit - some action scenes get a bit choppy. I have a dual core system.

I believe VLC is multi-threaded to run on both cores, but it's not as efficient at decoding x264 as The Core AVC codec. However, The Core AVC codec running through Media Player Classic isn't multi-threaded (don't know if that's a Core thing or an MPlayerC thing)

So, both VLC and MPlayerC (using The Core) get about the same performance.

What I would LOVE, is to find a player that could use The Core AVC codec, on both CPU cores... I'd be laughing!

I don't know if this is possible? If not, is there another alternative?

Cheers

Kado
30th December 2007, 13:25
Well something wrong with your system then.
Coreavc decoder v1.6 is multitreaded, cyberlink h264 decoder is multitreaded. ffdshow rev 1727 is supposed to be multitreaded as well. mpc + coreavc or cyberlinks decoder uses both cores in my system.
pentium d 3.6ghz 6800gs

LoRd_MuldeR
30th December 2007, 13:36
ffdshow rev 1727 is supposed to be multitreaded as well.
So far libavcodec (ffdshow, mplayer, etc.) supports multi-threaded decoding only for H.264 streams that were encoded with slices...

rohan
30th December 2007, 17:40
That explains quite a bit - I still have CoreAVC 1.1

Once I install 1.6 pro, would I be correct to assume that MPlayer Classic (6.4.9.0) will support multi-threading as well? I was under the assumption that both the codec and the player needed to make accomodations for multi-cores.

Dark Shikari
30th December 2007, 17:43
That explains quite a bit - I still have CoreAVC 1.1

Once I install 1.6 pro, would I be correct to assume that MPlayer Classic (6.4.9.0) will support multi-threading as well? I was under the assumption that both the codec and the player needed to make accomodations for multi-cores.Mplayer != Media Player Classic

Also, no, the codec and player are separate in this case... MPC works just fine with CoreAVC.

LoRd_MuldeR
30th December 2007, 20:23
Mplayer != Media Player Classic

MPC is a DirectShow-based player! It uses whatever Decoders you have installed (ffdshow, CoreAVC, Cyberlink, etc).
So if you install a multi-threaded H.264 decoder, then MPC will be multi-threaded when playing H.264 video. Otherwise it won't be!
MPC + ffdshow => not multithreaded yet. MPC + CoreAVC => multi-threaded.

MPlayer is an "all-in-one" player. It does not use (nor need) any filters/codecs/plugins, except it's own internal ones.
But both, ffdshow and MPlayer, use "libavcodec" code (from ffmpeg project) to decode H.264 streams. Same applies to VLC player.

ACrowley
31st December 2007, 21:02
So far libavcodec (ffdshow, mplayer, etc.) supports multi-threaded decoding only for H.264 streams that were encoded with slices...

Yes...
ffdhow pushes Both Cores on all my x264 encodes ..

I can play 1080p without Problems on my X2 4200 @ 5000
with ffdshow
Ofcourse with CoreAVC or Cyberlink too
There must be something wrong with his System

rohan
1st January 2008, 01:15
Well I don't know why ffdshow WOULD be able to play 1080p if it really is (as has been mentioned in this thread) NOT multi-threaded.

In terms of CoreAVC, it wasn't doing the trick because i had an older non-multi-threaded version installed.

Also - this is dual core, but only a Pentium D 805

LoRd_MuldeR
1st January 2008, 16:32
Well I don't know why ffdshow WOULD be able to play 1080p if it really is (as has been mentioned in this thread) NOT multi-threaded.
As said before: ffdshow uses the "libavcodec" decoder for H.264 and that decoder is multi-threaded. But its multi-threading support currently is based on slices. Hence multi-threading will not work for most H.264 streams. Especially not on those that were encoded with x264. That's because x264 doesn't use slices any more...

ACrowley
1st January 2008, 17:03
However.. i can play 1080p with ffdhow 1734 XXL without Problems with 50-70% CPU Load
And both Cores are in use with x264 encodes with (latest x264 Build) and also with BluRay/HDDVD AVC

vortex_hl
1st January 2008, 23:46
However.. i can play 1080p with ffdhow 1734 XXL without Problems with 50-70% CPU Load
And both Cores are in use with x264 encodes with (latest x264 Build) and also with BluRay/HDDVD AVC
xxl added Andreas' experimental multi threaded cabac entropy decoding functions in revision 1730. so if your content encoded with cabac, you see %20-30 speed up on multi core machine.

ACrowley
2nd January 2008, 15:18
xxl added Andreas' experimental multi threaded cabac entropy decoding functions in revision 1730. so if your content encoded with cabac, you see %20-30 speed up on multi core machine.


yep all encode with cabac.

So i think this is the Reason for the Multi Core Usage on latest ffdshwo XXXL Build. It pushes both Core with the same Load

KornX
2nd January 2008, 15:56
when i play the same content with ffdshow / mplayer,
the ffdshow uses about 30% more cpu than mplayer!
Has anybody noticed the same?
I can almost watch on my 2,4 GHz X2 h264 with mplayer,
but no way with ffdshow, even with the smp version!

KornX

LoRd_MuldeR
2nd January 2008, 21:12
when i play the same content with ffdshow / mplayer,
the ffdshow uses about 30% more cpu than mplayer!
Has anybody noticed the same?
I can almost watch on my 2,4 GHz X2 h264 with mplayer,
but no way with ffdshow, even with the smp version!

KornX

Almost certainly caused by DirectShow overhead! Maybe the video renderer has some effect too.

BTW: Which renderer do you use in your DirectShow-based player?
Maybe you like to try the "Overlay" renderer instead of VMR7/9, EVR or "Haali" renderer...

Sharktooth
4th January 2008, 02:35
use the good-old overlay... it's the faster.

AdAstra
26th July 2008, 04:36
This thread just helped me, so :thanks: Using mpc I tried core avc and all those ugly a/v desyncs are gone, with all of my 4 cores being used. Now i just downloaded the latest ffdshow beta, and turns out that decoding in mpc now is also multithreaded with this one. :)

clsid
26th July 2008, 13:35
Only part of the decoding process is currently multi-threaded in ffdshow. But soon ffdshow will have proper multi-threaded H.264 decoding and it will perform much better on multicores.

LoRd_MuldeR
26th July 2008, 13:59
But soon ffdshow will have proper multi-threaded H.264 decoding and it will perform much better on multicores.

Can you explain a bit more? :)

clsid
26th July 2008, 14:50
As you might know, ffdshow uses libavcodec from the FFmpeg project as its main decoding library. There is a Google Summer of Code (SoC) project in which someone is working on implementing multi-threading for the H.264 decoder. That project is almost finished now. But it may take some time before it make its way into the official trunk. For example an E-AC3 decoder was a project in last years SoC, and that has only recently been added to trunk.

KornX
26th July 2008, 16:34
when did that happen?
more than two weeks ago?

and LM, aehm actually you responded a while in my started thread about multithread decoding, you also suffer Alzheimer's? :)))

KornX

LoRd_MuldeR
26th July 2008, 17:26
and LM, aehm actually you responded a while in my started thread about multithread decoding, you also suffer Alzheimer's? :)))

I'm very well aware that ffdshow uses libavcodec. And I'm also very well aware that the "trunk" of libavcodec doesn't fully support multi-threading for H.264 yet :p
What I did not know is that there is a SoC project working on that. Also clsid's post (http://forum.doom9.org/showthread.php?p=1163178#post1163178) sounds like it will hit the official trunk very soon.

Therefore I asked for more detailed info... ;)


BTW: Your post here (http://forum.doom9.org/showthread.php?p=1159213#post1159213) was actually referring to some experimental branch of libavcodec. I first didn't notice that, but later I did :rolleyes:

pitch.fr
30th July 2008, 12:47
xxl added Andreas' experimental multi threaded cabac entropy decoding functions in revision 1730. so if your content encoded with cabac, you see %20-30 speed up on multi core machine.

I thought that was history, and that now both clsid/xxl versions were using MT on h264 ?

should I use XXL's exclusively ?

clsid
30th July 2008, 13:12
That patch is in SVN. So all SVN builds have it.

pitch.fr
30th July 2008, 14:25
ok thanks for the reply.

so there's no diff between clsid/xxl anymore then ?

_xxl
30th July 2008, 15:34
Yes, there's no diff anymore.

trulio
13th August 2008, 11:51
Here is the ultimate question: will a 1.6ghz hyperthreaded Atom CPU be sufficient to decode smoothly an h.264 720p media?

PS: the answer of _xxl:
"
Hi,

30% faster on 2 core cpu's, this is not an official patch, libavcodec supports only sliced based parallelism that doesn't any good or bad, because x264 doesn't do slices anymore.

Soon frame level parallelism will be available do to work of astrange.

Bye
"