I was wondering what it was doing under the covers.

It only uses 50% of my dual core, and so of course,
stutters on high demand video (1080p).

Isn't the decoding multi-threaded ?

might be issue with gpu? what do you have and what drivers?

if you disable desktop effects does it help?

have you tried playing the video with mPlayer or VLC?

google01103 wrote:might be issue with gpu? what do you have and what drivers?

if you disable desktop effects does it help?

have you tried playing the video with mPlayer or VLC?

Hi, I'm running an EVGA(Nvidia) 8600GT (256MB), driver version 260.19.36.

I'm trying to find out if something on my system is misbehaving,
or configured incorrectly, or some limitation or other.

If I run a 720p MKV in Dragon, it uses about 25% cpu. Running it in
Smplayer/Mplayer in xv mode, likewise uses about 25% cpu.

A 1080 video in Dragon uses 50% cpu and stutters and jerks.
Obviously maxed out a singe core, second core not used.
Likewise Smplayer (xv).

If I enable vdpau in Smplayer, 720p video plays fine (negligible cpu)
regardless of the "desktop effects" setting.
The 1080p video in smplayer/vdpau only plays if I disable "desktop effects"

To cut a long story short, neither player seems to use the multi-core
CPU. Why vdpau behaves like it does is a second mystery.

Any thoughts?

do not take as gospel (or even good) as I've never tried playing 1080p

- maybe 1080p requires more gpu ram then you have? Especially w/effects on
- multi-core might be a compile option that wasn't enabled? in one or the other players/decoders? you might visit the players forums and search/ask. Where'd you get VLC?
- you could up your drivers to the 270 series and see if it helps (might have to compile)

Thanks for the info.
Unfortunately I'm not a Linux expert.
I'm running PCLinuxOS 2010 and they advise strongly against
installing anything outside of their repository.

All I know is, it works in Windows XP, same box, dual boot.
The best result I get in XP is with CUDA. But even without,
Windows media player plays that 1080p file fine - using both cores of
the cpu at 95% utilization (CoreAVC non-CUDA mode).

It appears VLC is multi-threaded but not all codeces are http://forum.videolan.org/viewtopic.php ... eg#p248876 and http://forum.videolan.org/viewtopic.php ... 30#p214840

and similar for mPlayer http://tips4linux.com/make-mplayer-play ... -machines/ there maybe a reason packagers don't compile with the mt codec, you'd have to ask them but I think its still considered experimental

google01103,
thanks very much for your advice. You may be right about ffmpeg-mt,
I seen a few posts elsewhere - there were some sketchy instructions about
compiling mplayer to work with ffmpeg-mt, but I've never seen anything official.

Since Dragon hasn't any config options to speak of, what exactly is it doing?
Is it coded to use vdpau? If so, under what circumstances?
Does it use ffmpeg to do the decoding? If so, perhaps that's the reason it
can not take advantage of multi-processors.

Seems a bit behind the times, frankly. Dual core and better have been is common use
for three years now.

don't know much about Dragon, prefer sMplayer (mPlayer frontend) and VLC because Dragon and Kaffeine have no options. It uses the Xine libs to decode

Video codecs on Linux lag, it's a matter of resources available and there are licensing issues with some of them

some additional info, not a solution (at least not an easy one) see the last section dated 2009-02-20 http://www.mplayerhq.hu/design7/news.html

google01103 wrote:some additional info, not a solution (at least not an easy one) see the last section dated 2009-02-20 http://www.mplayerhq.hu/design7/news.html

Appreciate that, I'll research further.

Hello all,

I've always wondered this myself! Thanks for the info, I'll keep looking around. What a great Forum!


-myeah

update: ffmpeg-mt (support for multi-threading) is being merged in to the ffmpeg main branch and should be available when ffmpeg 0.7 ships http://www.h-online.com/open/news/item/ ... 14199.html

google01103 wrote:don't know much about Dragon, prefer sMplayer (mPlayer frontend) and VLC because Dragon and Kaffeine have no options. It uses the Xine libs to decode

I don't want to revive the topic nor to hi-jack it, so please excuse me for posting a reply; I just want to make a small correction: Dragon Player uses what Phonon uses - it does not depend on libxine I'm sure because the memory information window of the dragon process in krunner does not list xine, if phonon uses gstreamer for example.

dimitar wrote:

google01103 wrote:don't know much about Dragon, prefer sMplayer (mPlayer frontend) and VLC because Dragon and Kaffeine have no options. It uses the Xine libs to decode

I don't want to revive the topic nor to hi-jack it, so please excuse me for posting a reply; I just want to make a small correction: Dragon Player uses what Phonon uses - it does not depend on libxine I'm sure because the memory information window of the dragon process in krunner does not list xine, if phonon uses gstreamer for example.

I stand corrected, from userbase.kde.org

Due to using Solid and Phonon DragonPlayer is independent of any multimedia framework or hardware abstraction layer

But I would point out that for some reason it is a requirement in some packages (at least in openSuse)

Dragon Player's decoding of H.264 is dependent upon the decoding used by it's backend. You can see which backend is in use in System Settings > Multimedia > Phonon > Backends.